MVVM 패턴을 가진 WPF Prism Application Architechture

Question

현재 새로운 WPF 응용 프로그램에 프리즘을 소개하고 있으며 MVVM 패턴을 사용하고 있습니다. WPF 애플리케이션을 구성하는 초기 접근 방식은 모델 클래스를 유지하기 위해 하나의 프로젝트를 추가하는 것이 었습니다. 하나는 뷰 모델 클래스 등을 보유하는 것입니다. 이는 동일한 프로젝트에서 다른 논리적 구성 요소를 갖지 않도록 나중에 분할 될 수 있습니다. 그러나 이것은 프리즘을 사용할 때 (그리고 일반적으로 파라 랩을 사용할 때) 나쁜 구조로 나를 때립니다.

프리즘에서는 동일한 모듈과 관련된 모든 것이 동일한 모듈에 배치되는 다른 논리 모듈로 물건을 구조화하려고합니다. 그래서 이것은 내 응용 프로그램의 논리적 부분과 관련된 모든 부분을이 부분의 모듈에 넣어야한다고 말합니다. 이 구성 요소, 관련보기 모델 및 필요한 모델 클래스에 대한 몇 가지 다른보기가 가능할 수 있습니다. 그러나이 접근법을 사용하면 솔루션 주위에 모델이 산산조각 나게됩니다. 모델이 데이터베이스에 묶여 있기 때문에 결국 저를 나쁜 접근 방식으로 부딪칩니다. 나는 nhibernate를 사용하고 있으므로 데이터베이스는 실제로 "시각적"이되지는 않습니다.

그래서 나는 세 가지 구조를 본다. 이들 중 일반적으로 원하는 것이 있습니까? 아니면 응용 프로그램을 구성 해야하는 다른 방법이 있습니까?

1. 프로젝트 "모델", "뷰 모델"및 UserControls를 보유하는 것도 프로젝트합니다. 등..
2. 이 부분의 관련보기, 뷰 모델 및 모델을 포함하여 하나의 프로젝트 PR 논리적 부분.
3. View 및 ViewModel을 포함하여 하나의 프로젝트 PR 논리적 부분이지만 별도의 프로젝트에서 정의되는 모델. 논리적 관계가있는 경우 모든 모델 클래스에 대한 하나의 프로젝트조차도있을 수 있습니다.

모든 의견은 대단히 감사합니다!

Answer 1

모델을 별도의 프로젝트에 넣는 것은 괜찮습니다. 프리즘 스타일 아키텍처의 혜택을받을만큼 충분히 큰 경우 추천한다고 말하고 싶습니다. 이 모델은 V 및 VM의 수직 사일로에 국한되지 않지만 모든 아래에있는 하부 층입니다.

당신의 견해와보기 모델은 서로 가까이 생활하는 것이 의미가 있습니다. 보기 나보기 모델의 재사용을 찾을 수 있지만 그렇지 않으면 스트레스를받지 않습니다. 즉, 견해가 항상 특정보기 모델과 항상 묶인 것은 아니며 그 반대도 마찬가지입니다. 예를 들어, 나는 현재 분기에 필터링하는 모든 판매와보기 모델을 보여주는보기 모델이 있지만 동일한보기로 둘 다 장비 할 수 있습니다. 반면에는 동일한보기 모델의 파이 차트 대 막대 차트가 있습니다. 따라서 이것을 쪼개는 것은 절단 및 건조가 아닙니다. 그러나 단지보기/보기 모델 쌍보다 더 큰 덩어리를 찾을 수 있습니다. 영업 대 고객 관리 등.