많은 도구에서 권장 하는 RAD (드래그 앤 드롭) 방식의 사용자 인터페이스를 넘어 서면 Model-View-Controller , Model-View-Presenter 및 Model-View-ViewModel 이라는 세 가지 디자인 패턴을 보게 될 것 입니다. 내 질문에는 세 부분이 있습니다.
- 이러한 패턴은 어떤 문제를 해결합니까?
- 그것들은 어떻게 비슷합니까?
- 그것들은 어떻게 다릅니 까?
답변
모델 뷰-프레젠터
에서 MVP , 발표자보기위한 UI 비즈니스 로직이 포함되어 있습니다. View에서 모든 호출은 발표자로 직접 위임됩니다. 발표자는 또한보기에서 직접 분리되어 인터페이스를 통해 대화합니다. 단위 테스트에서 뷰를 조롱 할 수 있습니다. MVP의 일반적인 특징 중 하나는 양방향 디스패치가 많이 필요하다는 것입니다. 예를 들어, 누군가 “저장”단추를 클릭하면 이벤트 핸들러가 발표자의 “OnSave”메소드에 위임됩니다. 저장이 완료되면 Presenter는 인터페이스를 통해 View를 다시 호출하여 View에 저장이 완료되었음을 표시 할 수 있습니다.
MVP는 Web Forms에서 분리 된 프리젠 테이션을 달성하는 데 매우 자연스러운 패턴 인 경향이 있습니다. 그 이유는보기가 항상 ASP.NET 런타임에 의해 먼저 생성되기 때문입니다. 두 변종에 대한 자세한 내용을 확인할 수 있습니다 .
두 가지 주요 변형
패시브 뷰 : 뷰는 가능한 한 바보이며 거의 제로 로직을 포함합니다. 발표자는보기 및 모델과 대화하는 중간 사람입니다. 뷰와 모델은 서로 완전히 차폐되어 있습니다. 모델은 이벤트를 발생시킬 수 있지만 발표자는 뷰를 업데이트하기 위해 구독합니다. 패시브 뷰에는 직접 데이터 바인딩이 없으며, 대신 프리젠터가 발표자가 데이터를 설정하는 데 사용하는 세터 속성을 노출합니다. 모든 상태는보기가 아닌 발표자에서 관리됩니다.
- 장점 : 최대 시험 성 표면; 뷰와 모델의 깔끔한 분리
- 단점 : 모든 데이터 바인딩을 직접 수행함에 따라 더 많은 작업 (예 : 모든 세터 속성)
감독 컨트롤러 : 발표자는 사용자 제스처를 처리합니다. 뷰는 데이터 바인딩을 통해 모델에 직접 바인딩됩니다. 이 경우 모델을 뷰에 전달하여 모델에 바인딩 할 수있는 것은 발표자의 작업입니다. 발표자에는 버튼 누르기, 탐색 등의 제스처에 대한 논리도 포함됩니다.
- 장점 : 데이터 바인딩을 활용하면 코드 양이 줄어 듭니다.
- 단점 : 데이터 바인딩으로 인해 테스트 할 수있는 표면이 적고, 모델과 직접 통신하기 때문에 View에서 캡슐화가 적습니다.
모델 뷰 컨트롤러
에서 MVC , 컨트롤러보기 응용 프로그램이로드 될 때를 포함하여 어떤 행동에 대한 응답으로 표시 할 결정하기위한 책임이 있습니다. 동작이보기를 통해 발표자로 라우팅되는 MVP와 다릅니다. MVC에서 View의 모든 작업은 작업과 함께 Controller 호출과 관련이 있습니다. 웹에서 각 작업에는 응답하는 컨트롤러가있는 다른 쪽의 URL에 대한 호출이 포함됩니다. 해당 컨트롤러가 처리를 완료하면 올바른보기를 반환합니다. 이 순서는 응용 프로그램 수명 동안 계속 유지됩니다.
보기에서의 동작
-> 컨트롤러 호출
-> 컨트롤러 로직
-> 컨트롤러가보기를 반환합니다.
MVC의 또 다른 큰 차이점은 뷰가 모델에 직접 바인딩되지 않는다는 것입니다. 뷰는 단순히 렌더링되며 완전히 상태 비 저장입니다. MVC의 구현에서 View는 일반적으로 코드 뒤에 로직이 없습니다. 보기가 발표자에게 위임되지 않으면 절대로 호출되지 않기 때문에 절대적으로 필요한 MVP와 반대입니다.
프리젠 테이션 모델
살펴볼 또 다른 패턴은 프레젠테이션 모델입니다.무늬. 이 패턴에는 발표자가 없습니다. 대신보기가 프레젠테이션 모델에 직접 바인딩됩니다. 프리젠 테이션 모델은보기 전용으로 만들어진 모델입니다. 즉,이 모델은 도메인 분리에 대한 속성을 노출 할 수 있습니다. 이는 도메인 분리를 위반할 수 있기 때문입니다. 이 경우 프레젠테이션 모델은 도메인 모델에 바인딩되며 해당 모델에서 오는 이벤트를 구독 할 수 있습니다. 그런 다음보기는 프리젠 테이션 모델에서 오는 이벤트를 구독하고 그에 따라 자체적으로 업데이트됩니다. 프리젠 테이션 모델은 뷰가 조치 호출에 사용하는 명령을 노출 할 수 있습니다. 이 접근 방식의 장점은 PM이 뷰의 모든 동작을 완전히 캡슐화하므로 코드 숨김을 완전히 제거 할 수 있다는 것입니다.Model-View-ViewModel .
이 프리젠 테이션 모델에 대한 MSDN 문서 와의 섹션 WPF에 대한 복합 응용 프로그램 지침 에 대한 (전 프리즘) 로 구분 된 프리젠 테이션 패턴
답변
이것은 이러한 디자인 패턴의 많은 변형을 지나치게 단순화 한 것이지만 이것이 두 가지 차이점에 대해 생각하는 방식입니다.
MVC
MVP
답변
나는 이것에 대해 얼마 전에 블로그를 작성하여 Todd Snyder의 두 게시물의 차이점에 대한 훌륭한 게시물을 인용했습니다 .
패턴 간의 주요 차이점은 다음과 같습니다.
MVP 패턴
- 뷰가 모델에 더 느슨하게 결합됩니다. 발표자는 모델을 뷰에 바인딩해야합니다.
- 뷰와의 상호 작용이 인터페이스를 통해 이루어지기 때문에 단위 테스트가 더 쉬움
- 일반적으로 발표자에게 일대일로 표시합니다. 복잡한보기에는 여러 발표자가있을 수 있습니다.
MVC 패턴
- 컨트롤러는 동작을 기반으로하며 여러 뷰에서 공유 할 수 있습니다
- 표시 할보기를 결정할 책임이 있습니다.
내가 찾은 웹에서 가장 좋은 설명입니다.
답변
다음은 통신 흐름을 나타내는 그림입니다
답변
MVP가 반드시 뷰를 담당하는 시나리오 는 아닙니다 (예 : Taligent의 MVP 참조).
불행히도 사람들은 “그저보기 일뿐”(Pragmatic Programmer)과 모순되기 때문에 반 패턴과는 반대로 패턴 (담당자)으로 이것을 설교하고 있다는 것은 불행한 일입니다. “그냥보기 일뿐입니다”는 사용자에게 표시되는 최종보기가 응용 프로그램의 두 번째 관심사임을 나타냅니다. Microsoft의 MVP 패턴은 뷰 재사용을 훨씬 더 어렵게 만들고 편리하게 Microsoft 디자이너가 잘못된 연습을 장려하지 못하게합니다.
완벽하게 솔직히 말해서, MVC의 근본적인 관심사는 MVP 구현에 적용되며 그 차이는 거의 의미 론적이라고 생각합니다. 뷰 (데이터를 표시하는), 컨트롤러 (사용자 상호 작용을 초기화하고 제어하는 컨트롤러) 및 모델 (기본 데이터 및 / 또는 서비스)간에 우려를 분리하는 한 MVC의 이점을 얻을 수 있습니다 . 당신이 이점을 달성하고 있다면 누가 당신의 패턴이 MVC, MVP 또는 Supervising Controller인지 정말 걱정합니까? 유일한 실제 패턴은 MVC로 남아 있으며 나머지는 그 맛이 다릅니다.
이러한 다양한 구현을 종합적으로 나열한 이 흥미로운 기사를 고려하십시오 . 그것들은 모두 기본적으로 동일한 일을하지만 약간 다르게 작동한다는 것을 알 수 있습니다.
필자는 개인적으로 MVP가 최근 MVC인지 아닌지를 주장하는 의미 론적 비고 사이의 논쟁을 줄이거 나 Microsoft의 신속한 응용 프로그램 개발 도구를 정당화하기 위해 재치있는 용어로 다시 소개되었다고 생각합니다. 내 책에서 이러한 이유 중 어느 것도 별도의 디자인 패턴으로 존재한다는 것을 정당화하지 못합니다.
답변
MVP : 뷰가 담당합니다.
대부분의 경우보기는 발표자를 만듭니다. 발표자는 모델과 상호 작용하고 인터페이스를 통해보기를 조작합니다. 보기는 때때로 일부 인터페이스를 통해 발표자와 상호 작용합니다. 이것은 구현으로 귀착됩니다. 보기가 발표자에서 메소드를 호출하도록 하시겠습니까, 또는보기가 발표자가 청취하는 이벤트를 갖기를 원하십니까? 이것으로 요약됩니다.보기는 발표자에 대해 알고 있습니다. 보기는 발표자에게 위임됩니다.
MVC : 컨트롤러가 담당합니다.
컨트롤러는 일부 이벤트 / 요청에 따라 작성되거나 액세스됩니다. 그런 다음 컨트롤러는 적절한 뷰를 생성하고 모델과 상호 작용하여 뷰를 추가로 구성합니다. 컨트롤러는보기를 작성하고 관리합니다. 뷰는 컨트롤러의 슬레이브입니다. 보기는 컨트롤러에 대해 알지 못합니다.
답변
MVC (모델 뷰 컨트롤러)
입력은보기가 아닌 컨트롤러로 먼저 향합니다. 이 입력은 페이지와 상호 작용하는 사용자가 올 수도 있지만 브라우저에 특정 URL을 입력하는 것일 수도 있습니다. 두 경우 모두 일부 기능을 시작하기 위해 인터페이스되는 컨트롤러입니다. Controller와 View 사이에는 다 대일 관계가 있습니다. 단일 컨트롤러가 실행중인 작업에 따라 렌더링 할 다른보기를 선택할 수 있기 때문입니다. 컨트롤러에서 보기로의 단방향 화살표를 참고하십시오. View에 컨트롤러에 대한 지식이나 참조가 없기 때문입니다. 컨트롤러는 모델을 다시 전달하므로 뷰와 모델로 전달되는 예상 모델 사이에는 지식이 있지만이를 제공하는 컨트롤러는 아닙니다.
MVP (모델보기 발표자)
입력은 발표자가 아닌보기로 시작합니다. 보기와 관련 발표자간에 일대일 매핑이 있습니다. 보기에는 발표자에 대한 참조가 있습니다. 발표자는 View에서 트리거되는 이벤트에 반응하므로 View와 관련된 View를 인식합니다. 발표자는 모델에서 수행 한 요청 된 작업에 따라보기를 업데이트하지만보기는 모델을 인식하지 못합니다.
자세한 내용은 참조
