2010-08-08 2 views
2

Winforms 응용 프로그램을 다시 만들고 UI에 변형 Presentation Model pattern을 사용하고 싶습니다. 누군가 올바르게 설명하면 다음 설명에서 알려주시겠습니까?MVP/Presentation Model UI 패턴을 올바르게 구현합니까?


나는 다음과 같은 종속성을 설정하기로 결정했습니다 :

Model <---- Presentation Model <---- View 

즉 :

  • 모델 자체를 제외하고 아무것도 인식하지 못합니다.

  • 프리젠 테이션 모델에는 모델에 대한 참조가 있습니다 (반대의 경우도 마찬가지 임).

  • 보기에는 프레젠테이션 모델에 대한 참조가 있지만 그 반대의 경우는 아닙니다.

Winforms 데이터 바인딩을 사용하여보기 및 프레젠테이션 모델을 동기화합니다.

이제는이 모든 것이 매력처럼 작동합니다. 양식의 "닫기"버튼을 클릭하십시오. 프리젠 테이션 모델에는 뷰에 대한 참조가 없으므로 뷰에서 게시 한 이벤트를 구독 할 수 없습니다. 따라서 나는 다음과 같은 목발을 마련했습니다

Presentation Model     View 
+--+         +--+ 
| |         | | 
| |         | <--------X closeButton.Click event fires 
| |         | | 
| |       +--------X | 
| | CloseRequested = true |  | | 
| |       +--------> | 
| |         | | 
| | CloseRequested CloseRequested | | 
| <-----------------------------------< | 
| |         | | 
| X--------+       | | 
| |  | IsClosed = true   | | 
| <--------+       | | 
| |         | | 
| | IsClosed    MustClose | | 
| >-----------------------------------> | 
| |         | | 
| |         | X--------> view.Close() 
| |         | | 
+--+         +--+ 

즉 :

  • 사용자는 "닫기"버튼을 클릭합니다.

  • 단추의 Click 이벤트는 뷰에 캡처되며,이 속성은 CloseRequested 속성을 설정하여 반응합니다.

  • 데이터 바인딩은이 값을 프레젠테이션 모델의 해당 속성으로 전송합니다.

  • 프리젠 테이션 모델은 해당 속성 IsClosed을 설정하여이 변경에 반응합니다.

  • 데이터 바인딩은이 값을보기의 MustClose으로 전송합니다.

  • 보기 자체가 닫히면이 변경 사항에 반응합니다.

프리젠 테이션 모델

아주 잘보기에서 분리되고, 반대의 경우도 마찬가지 그러나 이 많은 작업은 하나의 버튼 명령을 처리하는 것입니다. 내가 결정한 의존성 그래프를 보면 더 쉬운 방법이 있을까요?

답변

2

저는 최근에 Windows Forms 응용 프로그램을 MVP 아키텍처로 변환 해 왔으며 여러분이 수행 한 것과 비슷한 방식으로 종속성을 설정 한 것처럼 보입니다. 그러나 뷰에 사용자 요청을 전달할 수있는 메서드를 정의하는 IPresenter 인터페이스가 있습니다. 뷰는 이미 발표자 및 참조에 대한 종속성이 있으므로 간단하게 요청 메소드를 호출하는 것이 현명합니다.

내 시스템에서 발표자는 모델의 이벤트를 수신하고 관심있는 모든보기가 들리는 자체 프리젠 테이션 이벤트를 시작합니다. 보기는 자신을 적절하게 업데이트하여 해당 이벤트에 응답하고 사용자 요청이 발표자에게 전달됩니다.

0

뷰는 표현 모델 (그러나 역도 마찬가지)에 대한 참조를 갖는다.

AFAIK 프리젠 테이션이 구체적인보기와 결합되지 않도록 IView 인터페이스에 대해보다 정확하게 볼 수 있도록하는 프레젠테이션이 있어야합니다. 그런 다음 프리젠 테이션 클래스에서 뷰 메소드를 호출하고 IView를 통해 뷰 이벤트에 가입 할 수 있습니다.

+0

MVP에는 여러 가지 변형이 있으며 두 가지 방법이 모두 수행 된 것으로 보았습니다. 설명하는 접근 방식에서 발표자는 모델과 IView 모두에 의존하게됩니다. 또한, 모든 뷰는 모든 IView 메소드를 처리하는 데 필요합니다. 처리하지도 신경 쓰지도 않습니다. 이 접근법에서 발표자는 모델에만 의존하며보기는 발표자에 따라 다릅니다. – Rich

+0

아니요, 프레젠테이션 모델이 MPV와 다른 접근 방식입니다. Thread Starter는 단위 테스트가 쉬워야하므로 UI에 대한 참조가 없어야합니다. – ktutnik

+0

@ktutnik Presenter는 Unit 컨트롤을 사용하여 Presenter 클래스를 테스트 할 수 있도록 View 컨트롤이 아닌 IView 인터페이스에 대한 참조를 가져 왔습니다. – Arseny

1

내 의견입니다.

프리젠 테이션 모델 작업은 데이터 바인딩을 위해 100 % UI 지원이 필요합니다. WPF조차도 CLOSE 동작을 Bindable로 만들지 않습니다. MessageBox Confirmation과 같은 프레젠테이션 모델에서는 원활하게 작동하지 않습니다. 심지어 Presenter 인터페이스로 추상화 될 수 있지만 여전히 맛이 좋지 않으며 단순함이 희생됩니다. 한편, 제시 모델의 주요 목적은 뷰 로직을 테스트하는 것이다. 경우에 따라 "닫는 동작"이 일부 논리가 있기 전에 단위 테스트를 거친 후 코드가 유일한 선택 일 것입니다. 하지만 간단한 확인 만하면 "끝내시겠습니까?"라고 표시 한 다음 단원 테스트가 필요하지 않으므로 프레젠테이션 모델이 아닌보기에 배치하는 것이 좋습니다.

+0

Winforms의 데이터 바인딩이 완벽하지 않다는 것을 알고 있습니다. 예를 들어 UI 컨트롤에만 사용할 수 있으며 POCO에는 사용할 수 없으며 이름에서 알 수 있듯이 이벤트는 지원하지 않지만 속성 만 지원합니다. 그러나 WinForms에서 MVP 패턴을 구현할 때 이것이 근본적인 문제입니까? – stakx

+0

예! 기본은 바인딩이기 때문입니다. WPF에서는 MVVM (Model - View - View Model)이라고하며 Adobe Flex는 (Presentation Model)이라고합니다. ** 대화 확인 mvvm ** 또는 ** 플렉스 검증 프레젠테이션 모델 **을 검색 할 수 있습니다 ** 프레젠테이션 모델 패턴이 선명도보다 더 많은 문제를 일으키는 방법을 확인할 수 있습니다. 그것을 나쁜 패턴이라고 말하는 것은 아니지만 그것을 100 % 작업으로 만들기 위해서는 데이터 바인딩을위한 100 % View Support가 필요합니다. MVP와 프리젠 테이션 모델이 다른 것을 기억하십시오. http://nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm/ – ktutnik