지난 2 년 동안 소프트웨어 개발에 대해 배우면서 더 많은 학습을 할 수있게되었습니다. 현재 문제가있는 하나의 회색 영역은 응용 프로그램에 몇 개의 레이어가 있어야하는지 결정하려고하는 것입니다. 예를 들어 WPF MVVM 응용 프로그램에서 어떤 레이어링 방식이 좋습니까? 다음과 같이 너무 분리되어 있습니까? 레이어링을 언급 할 때 각 레이어에 대한 새로운 클래스 라이브러리를 만드는 것을 의미합니다.얼마나 많은 레이어가 너무 많습니까?
또는 비 MVVM 응용 프로그램가
함께 레이어를 실행하고 단지 각 레이어에 대해 폴더를 만들 만족할 만합니까? 이 회색 영역의 모든 색상이 표시됩니다.
Layered Architecture:이 기사에서는 .NET/WPF 리치 클라이언트 애플리케이션을위한 구체적인 예제 아키텍처에 대해 설명합니다. 또한 아키텍처는 Model-View-ViewModel (MVVM) 패턴의 참여자를 찾을 수있는 계층을 보여줍니다.
대답은 다릅니다. 우선, 별도의 클래스 라이브러리가 항상 별도의 "레이어"를 의미하는 것은 아닙니다. 계층이란 관련된 기능을 개념적으로 그룹화 한 것으로 하나의 어셈블리에서 자체적으로 나타낼 수도 있고 그렇지 않을 수도 있습니다.
생성하는 레이어의 수는 실제로 사용중인 문제에 따라 다릅니다. 전통적으로 WPF MVVM 애플리케이션은 적어도 3 개의 레이어 (모델, 뷰, 뷰 모델)를 포함하지만 실제로 다양 할 수 있습니다. 흔히 Model 객체가 다른 컨텍스트에서 사용되는 POCO이기 때문에 같은 어셈블리와 모델에서 Views와 ViewModel을 볼 수 있습니다.
질문에 대한 답변은 정말 없습니다. 전적으로 귀하의 문제에 달려 있습니다. "레이어링"및 분리의 이점은 유지 관리 가능성을 높이고 코드 재사용을 촉진하며 전반적인 명확성을 향상시키는 것입니다.
나는 당신이 현재의 겹겹이 솔루션으로 이러한 목표에 도달하지 못한다면 개선의 여지가 있다고 주장 할 것입니다. 이 증가하면 레이어는으로 줄어들고 은 선명도 또는 유지 보수성이 떨어집니다. 하나의 "레이어"만 가지고 있고 부풀어 오르는 경우 레이어를 추가 할 수 있습니다.
엄격한 "패턴"을 따르기 위해 결론을 내놓지 마십시오. 패턴이 당신과 당신의 문제가 명확한 장점을 가지고 있다면 구현하십시오. 그러나 왜 그렇게하는지, 각 "층"의 목표는 무엇인지 이해하십시오..
는 다음과 같은 영역을 고려 :
... 당신이 가치 이들 중 어느 기반으로 아키텍처를 조정합니다. 아마 다른 중요한 부분들을 놓치고 있을지 모르지만, 당신은 그 아이디어를 얻었습니다. 이 사실에 대한 옳고 그른 대답은 없습니다.
레이어 자체가 유지 관리 가능성을 향상시키는 것과는 대조적으로 프로젝트의 유지 관리가 어려워 질 경우 응용 프로그램에는 레이어가 너무 많습니다.
실제로 나의 시스템은 항상 다음과 같이 구성됩니다 :'front proxy' MVC 컨트롤러와 같은 사용자 요청을 받아들이는 것; 'business'는 액션에서 * sequence *의 오케스트레이션을 처리합니다; 'compute'는 모든 알고리즘 작업, 데이터 집계 등을 처리합니다; 모든 sql 호출, 원격 웹 요청, 파일 시스템 등을 처리하는'data access'가 있습니다. –
너무 많은 정확한 레이어 수는 필요한 것보다 1입니다.
몇 가지 레이어가 너무 적습니까? –
커뮤니티 위키? 이것에 대한 '정확한'대답은 없습니다 ... 회색 영역은 어때요? :) –
대답은 물론 42 –