MVVM 설명

우리는 첫 번째 WPF 응용 프로그램을 작성하려고하고 있으며 MVVM 패턴에 익숙해지고 있습니다. 우리는 많은 Winform 응용 프로그램을 구축했으며 매우 성공적인 아키텍처를 보유하고 있습니다. 아키텍처를 번역하거나 아키텍처의 특정 부분이 MVVM 모델에 적합한 위치를 결정하는 데 약간의 문제가 있습니다.

역사적으로 우리는 BusinessLogic dll과 통신하는 Gui (메인 exe)를 가지고 있습니다. BusinessLogic은 웹 서비스를 통해 DAL dll과 통신하고 DAL은 DB와 상호 작용합니다. DAL, BusinessLogic 및 GUI는 모두 동일한 BusinessObjects dll을 참조합니다.

MVVM으로의 전환 중 일부는 매우 간단합니다. Gui는 여전히 뷰를 포함하고 BusinessOjbects는 여전히 모델을 포함하며 DAL은 여전히 ​​DB와 상호 작용합니다 (구현하는 기술은 변경 될 수 있음).

확실하지 않은 것은 BusinessLogic 구성 요소입니다. 역사적으로 이것은 GUI가 뷰에서 컨트롤을 채우기 위해 호출하는 함수를 제공합니다 (예 : GetCustomerList는 Customer 객체 또는 일반적인 CRUD 함수 목록을 반환합니다).

우리가 가지고있는 주요 요점은 MVVM 패턴이 ViewModel을 수용하기 위해 추가 구성 요소를 호출하는지 또는 생각을 변경하고 BusinessLogic 구성 요소로 사용한 것을 ViewModels로 마이그레이션하는 것입니까?

BusinessLogic 구성 요소가 ViewModel을 나타 냅니까?

일반적으로 비즈니스 모델을 뷰 모델 계층에 배치하지 않습니다. 그러나 "비즈니스 로직"이라는 용어는 오해의 소지가 있습니다.

Eric Evans는 비즈니스 로직이 두 가지 범주로 구분되는 모델을 사용합니다.

• 도메인 로직-해결하려는 실제 문제 도메인과 관련된 로직
• 응용 프로그램 논리-응용 프로그램을 작성하고 있다는 사실과 관련된 논리

그는 회계 응용 프로그램의 예를 언급합니다. 계정, 게시물, 세금 계정 등에 대한 규칙은 계정 도메인과 관련된 도메인 규칙, 규칙입니다. CSV 가져 오기 / 내보내기에 대한 논리는 회계 도메인과 관련이 없습니다. 이러한 규칙은 우리가 소프트웨어 응용 프로그램을 구축하기 때문에 순수하게 존재합니다. 이것들은 어플리케이션 로직의 예입니다.

도메인 규칙은 절대로 뷰 모델 계층으로 들어 가지 않아야합니다. MVVM 패턴을 따르는 경우 도메인 규칙이 모델 계층에서 문제없이 진행됩니다.

CSV 가져 오기 / 내보내기와 같은 응용 프로그램 규칙 은 뷰 모델 계층으로 이동할 수 있습니다. 그러나 개인적으로, 나는 그것을 별도의 응용 프로그램 논리 계층으로 분리하는 것을 선호합니다.

뷰 모델은 매우 단순해야합니다. 해당 모델에서보기에 필요한 데이터 조회,보기가 변경 될 때 모델 업데이트, 모델의 이벤트 청취 및 해당 이벤트를보기로 전파하여 모델이 장면 뒤에서 업데이트 될 때보기가 업데이트 될 수 있음 (적용된다면).

개인적으로 뷰 모델 레이어에는 프리젠 테이션 로직이라는 한 가지 유형의 로직 만 포함되도록해야합니다.

예.

비즈니스 로직 계층은 VM 계층으로 표시됩니다. 그래서 당신의 정신 모델을 마이그레이션하십시오.

멘탈 모델 마이그레이션을 돕기 위해 GUI (View) 개체를 VM 계층 내의 개체에 바인딩해야한다는 약간의 미묘한 차이가 있습니다. 그 바인딩은 | 뷰가 더 이상 다른 것을 검색하기 위해 "호출"하는 레이어가 아님을 나타냅니다. 대신 데이터 검색 요청이 VM에서 발생합니다.

더 잘 설명하려면 : 그렇습니다. 호출 할 일련의 작업을 트리거하려면보기 내의 개체를 변경해야합니다. 그러나보기는 전화 자체를하지 않습니다. 이 경우 버튼 클릭을 View 내에서 변경되는 것으로 간주하지만 여전히 전화를 걸지 않습니다.

첫 번째 경우 해당 View 개체는 VM 개체에 바인딩됩니다. VM은 바인딩 된 객체에서 속성 변경 이벤트를 수신하고 있어야합니다. 그런 다음 개체 변경 이벤트를 VM 함수에 연결하여 모델을 호출 할 수 있습니다.

두 번째 경우 (버튼 클릭 이벤트), 변경 (클릭) 이벤트는 VM에 의해 노출 된 함수 호출에 연결될 수 있습니다.

어느 쪽이든, 항상 VM으로 시퀀싱되고 모델을 호출하고 DAL / DB를 호출하는 이벤트입니다.

일부 WinForm 코드는 WinForm GUI의 코드 숨김에서 직접 DB 레이어를 호출하는 데 사용되기 때문에 가져옵니다. 이러한 접근 방식은 MVVM이 제공하는 분리를 깨뜨립니다.

본질적으로 BusinessLogic dll을 ViewModel 레이어로 바꾸는 것이 맞지만 View / UI 레이어가 ViewModel / BusinessLogic 레이어와 상호 작용하는 방식이 가장 큰 차이점이라고 생각합니다.

WinForms에서 GUI는 응용 프로그램이며 응용 프로그램 흐름을 담당합니다. WPF / MVVM에서 ViewModel은 응용 프로그램이며 GUI는 ViewModel과 상호 작용하기위한 사용자 친화적 인 인터페이스가됩니다.

예를 들어 WinForms를 사용하면 DataGrid와 Button이있을 수 있으며 해당 Button을 클릭 BusinessLogicLayer.GetProducts()하면 결과 Product 개체를 호출 하여 DataGrid에로드합니다.

WPF와 함께, 당신은 포함하는 뷰 모델 것 ObservableCollection<Products>과를 ICommand GetProducts하고 명령을 실행하면 DAL로드 제품의 컬렉션을 호출합니다. 그러나 사용자 친화적 인 인터페이스를 제공하기 위해 Products 컬렉션의 DataGrid와 GetProducts 명령의 단추를 사용하여 ViewModel을 렌더링하는 View를 만듭니다.

필자는 실제로 블로그 에서 Winforms에서 WPF로 이동할 때 사고 방식의 변화에 대해 상당히 최근의 블로그 게시물을 작성 했으며 차이점을 요약하는 가장 좋은 방법은 다음 그림과 같다고 생각합니다.