MVP와 MVC는 무엇이며 차이점은 무엇입니까?

많은 도구에서 권장 하는 RAD (드래그 앤 드롭) 방식의 사용자 인터페이스를 넘어 서면 Model-View-Controller , Model-View-Presenter 및 Model-View-ViewModel 이라는 세 가지 디자인 패턴을 보게 될 것 입니다. 내 질문에는 세 부분이 있습니다.

1. 이러한 패턴은 어떤 문제를 해결합니까?
2. 그것들은 어떻게 비슷합니까?
3. 그것들은 어떻게 다릅니 까?

모델 뷰-프레젠터

에서 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를 인식합니다. 발표자는 모델에서 수행 한 요청 된 작업에 따라보기를 업데이트하지만보기는 모델을 인식하지 못합니다.

자세한 내용은 참조

질문에 대한 많은 답변이 있지만, 두 가지를 명확하게 비교하는 정말 간단한 답변이 필요하다고 느꼈습니다. MVP 및 MVC 앱에서 사용자가 영화 이름을 검색 할 때 구성한 내용은 다음과 같습니다.

사용자 : 클릭…을 클릭하십시오

보기 : 누구입니까? [ MVP | MVC ]

사용자 : 방금 검색 버튼을 클릭했습니다…

보기 : 좋아, 잠깐만… [ MVP | MVC ]

( 보기 호출 발표자 | 컨트롤러 ...) [ MVP | MVC ]

보기 : Hey Presenter | Controller 사용자가 방금 검색 버튼을 클릭했습니다. 어떻게해야합니까? [ MVP | MVC ]

발표자 | Controller : Hey View , 해당 페이지에 검색어가 있습니까? [ MVP | MVC ]

보기 : 예,… 여기 있습니다. "피아노"[ MVP | MVC ]

발표자 : 감사합니다. 보기 … 모델 에서 검색어를 찾는 중 진행률 표시 줄을 보여주십시오 [ MVP | MVC ]

( 발표자 | 컨트롤러 가 모델을 부릅니다 …) [ MVP | MVC ]

발표자 | Controller : Hey Model ,이 검색어와 일치하는 것이 있습니까? : "piano"[ MVP | MVC ]

모델 : Hey Presenter | 컨트롤러 , 확인하겠습니다 ... [ MVP | MVC ]

( 모델 이 영화 데이터베이스에 쿼리하는 중…) [ MVP | MVC ]

( 잠시 후 ... )

-------------- 이것은 MVP와 MVC가 분기되기 시작하는 곳입니다. ---------------

모델 : Presenter 의 목록을 찾았습니다 . 여기는 JSON "[{"name ":"Piano Teacher ","year ": 2001}, {"name ":"Piano ","year ": 1993}에 있습니다. ]”[ MVP ]

모델 : 사용 가능한 결과가 있습니다 ( 컨트롤러) . 인스턴스에서 필드 변수를 만들고 결과로 채웠습니다. 이름은 "searchResultsList"입니다. [ MVC ]

( 발표자 | 컨트롤러 감사 모델 및 다시 보기 ) [ MVP | MVC ]

발표자 : View 를 기다려 주셔서 감사합니다. 일치하는 결과 목록을 찾아서 ""Piano Teacher 2001 ","Piano 1993 "]과 같은 형식으로 정렬했습니다. 세로 목록으로 사용자에게 보여주세요. 또한 진행률 표시 줄을 숨기십시오 [ MVP ]

컨트롤러 : 감사 대기에 대한 보기를 , 나는 물었다 모델을 검색 쿼리에 대해. 일치하는 결과 목록을 찾아서 인스턴스 내의 "searchResultsList"라는 변수에 저장했다고합니다. 거기에서 얻을 수 있습니다. 또한 진행률 표시 줄을 숨기십시오 [ MVC ]

보기 : 감사합니다. 발표자 [ MVP ]

보기 : 감사합니다 "컨트롤러"[ MVC ] (이제 보기 자체에 의문을 제기합니다. 모델 에서 얻은 결과 를 사용자에게 어떻게 제시해야합니까? 영화 제작 연도가 가장 먼저 또는 마지막에 있어야합니까 ...? 수직 또는 수평 목록에 있습니까? ...)

관심이 있으시다면 여기 Github 저장소와 함께 앱 아키텍처 패턴 (MVC, MVP, MVVP, 클린 아키텍처 등)을 다루는 일련의 기사를 작성했습니다 . 샘플이 Android 용으로 작성되었지만 기본 원칙을 모든 매체에 적용 할 수 있습니다.

• MVP = 모델 뷰 프리젠터

• MVC = 모델 뷰 컨트롤러

  1. 두 프리젠 테이션 패턴. 모델 (도메인 객체 생각), 화면 / 웹 페이지 (보기) 및 UI 작동 방식 (발표자 / 컨트롤러) 간의 종속성을 구분합니다.
  2. 그것들은 개념 상 상당히 유사하며, 사람들은 취향에 따라 발표자 / 컨트롤러를 다르게 초기화합니다.
  3. 차이점에 대한 훌륭한 기사가 여기에 있습니다 . 가장 주목할만한 것은 MVC 패턴에 모델이 뷰를 업데이트한다는 것입니다.

모델 뷰 컨트롤러

MVC 는 소프트웨어 응용 프로그램 아키텍처의 패턴입니다. 애플리케이션 로직을 3 개의 개별 파트로 분리하여 모듈화와 협업 및 재사용 용이성을 촉진합니다. 또한 응용 프로그램을보다 유연하고 반복적으로 환영하며 응용 프로그램을 다음 구성 요소로 분리합니다.

• 데이터 및 비즈니스 로직 처리를위한 모델
• 사용자 인터페이스 및 응용 프로그램을 처리하기위한 컨트롤러
• 그래픽 사용자 인터페이스 객체 및 프리젠 테이션 처리를위한 뷰

좀 더 명확하게하기 위해 간단한 쇼핑 목록 앱을 상상해 봅시다. 우리가 원하는 것은 이번 주에 구매해야하는 각 품목의 이름, 수량 및 가격 목록입니다. 아래에서는 MVC를 사용하여이 기능 중 일부를 구현하는 방법에 대해 설명합니다.

모델 뷰-프레젠터

• 모델 뷰 (사용자 인터페이스)에 표시되는 데이터이다.
• 보기 발표자로 데이터를 표시 (모델) 및 경로의 사용자 명령 (이벤트) 데이터에 따라 행동 할 것을 인터페이스입니다. 보기에는 일반적으로 발표자에 대한 참조가 있습니다.
• 발표자 (MVC에서 컨트롤러에 의해 연주)은 "중간 사람"이고, 뷰와 모델 모두에 대한 참조를 가지고있다. “모델”이라는 단어 는 오해의 소지가 있습니다. 오히려 모델을 검색하거나 조작하는 비즈니스 로직 이어야합니다 . 예를 들어 : 데이터베이스 테이블에 사용자를 저장하는 데이터베이스가 있고보기에서 사용자 목록을 표시하려는 경우 발표자는 발표자가 목록을 쿼리 할 데이터베이스 비즈니스 로직 (예 : DAO)에 대한 참조를 갖습니다. 사용자 수

간단한 구현으로 샘플을 보려면 이 GitHub 게시물을 확인하십시오

데이터베이스에서 사용자 목록을 쿼리하고 표시하는 구체적인 워크 플로는 다음과 같이 작동 할 수 있습니다.

MVC 와 MVP 패턴 의 차이점 은 무엇입니까 ?

MVC 패턴

• 컨트롤러는 동작을 기반으로하며 여러 뷰에서 공유 할 수 있습니다

• 표시 할보기 결정을 담당 할 수 있습니다 (전면 컨트롤러 패턴)

MVP 패턴

• 뷰가 모델에 더 느슨하게 결합됩니다. 발표자는 모델을 뷰에 바인딩해야합니다.

• 뷰와의 상호 작용이 인터페이스를 통해 이루어지기 때문에 단위 테스트가 더 쉬움

• 일반적으로 발표자에게 일대일로 표시합니다. 복잡한보기에는 여러 발표자가있을 수 있습니다.

또한 다른 유형의 MVP도 있다는 점을 기억해야합니다. Fowler는이 패턴을 수동보기와 감시 컨트롤러의 두 가지로 나누었습니다.

Passive View를 사용하는 경우 일반적으로 View는 기본 UI 위젯에 거의 직접 속성을 매핑하는 세분화 된 인터페이스를 구현합니다. 예를 들어 이름 및 주소와 같은 속성을 가진 ICustomerView가있을 수 있습니다.

구현은 다음과 같습니다.

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Presenter 클래스는 모델과 대화하고 뷰에 "매핑"합니다. 이 접근 방식을 "패시브 뷰"라고합니다. 장점은 뷰를 테스트하기 쉽고 UI 플랫폼 (Web, Windows / XAML 등)간에 쉽게 이동할 수 있다는 것입니다. 단점은 WPF 및 Silverlight 와 같은 프레임 워크에서 실제로 강력한 데이터 바인딩과 같은 것을 활용할 수 없다는 것 입니다.

MVP의 두 번째 특징은 Supervising Controller입니다. 이 경우 View에는 Customer라는 속성이있을 수 있으며이 속성은 다시 UI 위젯에 데이터 바인딩됩니다. 뷰 동기화 및 미세 관리에 대해 생각할 필요가 없으며 Supervising Controller는 필요한 경우 (예 : 복잡한 상호 작용 논리) 개입하여 도움을 줄 수 있습니다.

MVP의 세 번째 "맛"(또는 다른 패턴이라고도 함)은 프레젠테이션 모델 (또는 때로는 Model-View-ViewModel이라고도 함)입니다. MVP와 비교하여 M과 P를 하나의 클래스로 "병합"합니다. UI 위젯이 데이터 바인딩 된 고객 오브젝트가 있지만 "IsButtonEnabled"또는 "IsReadOnly"등과 같은 추가 UI 관련 필드도 있습니다.

UI 아키텍처에서 찾은 최고의 리소스는 Jeremy Miller가 The Your Your Own CAB Series Table of Contents 에서 수행 한 일련의 블로그 게시물이라고 생각합니다 . 그는 MVP의 모든 특징을 다루고 C # 코드를 보여주었습니다.

또한 YouCard Re-visited : ViewModel 패턴 구현 에서 Silverlight와 관련하여 Model-View-ViewModel 패턴에 대해 블로그를 작성했습니다 .

그것들은 각각 다른 문제를 해결하고 아래처럼 만들 수 있습니다

MVC, MVP 및 MVVM에 대한 완벽한 비교 도 있습니다.

이 두 프레임 워크는 데이터 소스 (모델), 응용 프로그램 논리 (또는이 데이터를 유용한 정보로 변환) (컨트롤러 / 발표자) 및 표시 코드 (보기)와의 상호 작용과 같은 우려를 분리하는 것을 목표로합니다. 경우에 따라 모델을 사용하여 데이터 소스를 더 높은 수준의 추상화로 변환 할 수도 있습니다. 이에 대한 좋은 예는 MVC Storefront 프로젝트 입니다.

MVC와 MVP의 차이점에 대한 논의가 있습니다 .

차이점은 MVC 애플리케이션에서 전통적으로 뷰와 컨트롤러가 모델과 상호 작용하지만 서로 상호 작용하지 않는다는 것입니다.

MVP 디자인은 발표자가 모델에 액세스하고 뷰와 상호 작용하도록합니다.

그러나 ASP.NET MVC는 이러한 정의에 따라 컨트롤러가 모델에 액세스하여 로직을 갖지 않는 뷰를 채 웁니다 (컨트롤러가 제공 한 변수 만 표시).

MVP와 ASP.NET MVC의 차이점에 대한 아이디어를 얻으려면 Scott Hanselman의 MIX 프레젠테이션 을 확인하십시오 .

둘 다 프리젠 테이션과 비즈니스 로직을 분리하려고하는 패턴이며, 비즈니스 로직을 UI 측면에서 분리합니다.

구조적으로 MVP는 MVC가 Front Controller 기반 접근 방식 인 Page Controller 기반 접근 방식입니다. 즉, MVP 표준 웹 양식 페이지 수명주기는 코드 숨김에서 비즈니스 로직을 추출하여 향상됩니다. 즉, page는 http 서비스를 제공하는 것입니다. 즉, MVP IMHO는 웹 양식 진화 유형의 향상입니다. 반면에 MVC는 요청이 페이지가로드되기 전에 컨트롤러 클래스에 의해 가로 채기 때문에 비즈니스 로직이 실행 된 후 컨트롤러가 페이지에 덤프 된 데이터를 처리 한 최종 결과 ( "보기") 때문에 게임을 완전히 변경합니다. MVC는 라우팅 엔진으로 강화 된 MVP의 Supervising Controller의 풍미를 많이 보여줍니다.

둘 다 TDD를 가능하게하고 단점과 단점이 있습니다.

이 중 하나를 선택하는 방법에 대한 결정 IMHO는 ASP NET 웹 양식 유형의 웹 개발에 얼마나 많은 시간을 투자했는지에 따라 결정되어야합니다. 웹 양식에 능숙하다고 생각되면 MVP를 추천합니다. 페이지 수명주기 등과 같은 것들에서 너무 편안하지 않다면 MVC가 여기에 갈 수있는 방법 일 수 있습니다.

이 주제에 대해 좀 더 자세한 내용을 제공하는 또 다른 블로그 게시물 링크가 있습니다.

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

MVP와 MVC를 모두 사용했지만 개발자가 두 패턴의 기술적 차이점에 중점을 두는 경향이 있지만 IMHO에서 MVP의 요점은 다른 것보다 채택의 용이성과 관련이 있습니다.

이미 웹 양식 개발 스타일에 대한 좋은 배경을 가진 팀에서 일하고 있다면 MVC보다 MVP를 도입하는 것이 훨씬 쉽습니다. 이 시나리오에서 MVP는 빠른 승리라고 말할 수 있습니다.

내 경험에 따르면 팀을 웹 양식에서 MVP로, 그리고 MVP에서 MVC로 옮기는 것이 비교적 쉽다는 것을 알 수 있습니다. 웹 양식에서 MVC로 이동하는 것이 더 어렵습니다.

여기에 내 친구가 MVP 및 MVC에 대해 게시 한 일련의 기사에 대한 링크가 있습니다.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

MVP에서보기는 발표자로부터 데이터를 가져 오며 MVC에서는 컨트롤러가보기에서 푸시하여 모델에서 데이터를 가져오고 설정하는 동안 모델에서 데이터를 가져오고 준비 / 정규화합니다.

MVP에서는 여러 유형의 발표자와 작업하는 단일보기와 다른 여러 시점과 작업하는 단일 발표자를 가질 수 있습니다.

MVP는 일반적으로 Microsoft WPF 바인딩 프레임 워크 또는 HTML5 및 Java에 대한 다양한 바인딩 프레임 워크와 같은 일종의 바인딩 프레임 워크를 사용합니다.

이러한 프레임 워크에서 UI / HTML5 / XAML은 각 UI 요소가 표시하는 발표자의 속성을 알고 있으므로보기를 발표자에 바인딩 할 때보기는 속성을 찾고 해당 속성에서 데이터를 그리는 방법과 방법을 알고 있습니다. 사용자가 UI에서 값을 변경할 때 설정합니다.

예를 들어 모델이 자동차 인 경우 발표자는 일종의 자동차 발표자이며 자동차 속성 (연도, 제작자, 좌석 등)을보기에 노출합니다. 뷰에는 'car maker'라는 텍스트 필드에 발표자 메이커 속성이 표시되어야합니다.

그런 다음 많은 다른 유형의 발표자에게 뷰에 바인딩 할 수 있으며 모두 메이커 속성이 있어야합니다. 평면, 기차 또는 뷰가 중요하지 않은 뷰일 수 있습니다. 뷰는 합의 된 인터페이스를 구현하는 한 발표자로부터 데이터를 가져옵니다.

이 바인딩 프레임 워크는 스트립하면 실제로 컨트롤러입니다 :-)

따라서 MVP를 MVC의 진화로 볼 수 있습니다.

MVC는 훌륭하지만 문제는 일반적으로 뷰 당 컨트롤러입니다. 컨트롤러 A는 뷰 A의 필드를 설정하는 방법을 알고 있습니다. 이제 뷰 A가 모델 B의 데이터를 표시하도록하려면 모델 A를 알기 위해 컨트롤러 A가 필요하거나 인터페이스가있는 객체를 수신하려면 컨트롤러 A가 필요합니다. 바인딩이없는 MVP 만 또는 컨트롤러 B에서 UI 세트 코드를 다시 작성해야합니다.

결론-MVP와 MVC는 모두 UI 패턴을 분리하지만 MVP는 일반적으로 아래에 MVC 인 바인딩 프레임 워크를 사용합니다. THUS MVP는 MVC보다 아키텍처 수준이 높으며 MVC 이상의 래퍼 패턴입니다.

내 소소한 짧은 견해 : MVP는 대규모 용이고 MVC는 소규모 용입니다. MVC를 사용하면 언젠가 V와 C가 M에 직접 바인딩되지 않고 단일 불가분의 구성 요소의 양면을 볼 수 있으며 UI 컨트롤 및 기본 위젯과 같이 더 짧은 스케일로 내려갈 때 필연적 으로이 부분에 빠질 수 있습니다. 이 세분성 수준에서 MVP는 의미가 없습니다. 반대로 규모가 커지면 책임을 명확하게 할당하는 것과 마찬가지로 적절한 인터페이스가 더 중요 해지고 MVP가됩니다.

다른 한편으로, 엄지 손가락의이 척도 규칙은 플랫폼 특성이 웹과 같이 구성 요소들 사이에서 MVP보다 MVC를 구현하는 것이 더 쉬운 것처럼 보이는 구성 요소들간에 어떤 종류의 관계를 선호 할 때 가중치가 거의 없을 수 있습니다.

Erwin Vandervalk (및 첨부 된 기사 ) 의이 이미지 는 MVC, MVP 및 MVVM에 대한 최고의 설명, 유사점 및 차이점에 대한 것입니다. 기사는 기사의 제목은 단어 "MVC"와 "MVP"를 포함하지 않기 때문에 "MVC, MVP 및 MVVM"에 대한 조회 검색 엔진 결과에 표시되지 않습니다 가장 좋은 설명이라고 생각합니다.

(이 기사 는 밥 마틴 (Bob Martin) 삼촌이 말한 내용과 도 일치합니다. MVC는 원래 시스템 아키텍처가 아닌 작은 UI 구성 요소를 위해 설계되었습니다)

MVC에는 여러 버전이 있으며이 답변은 Smalltalk의 원래 MVC에 대한 것입니다. 간단히 말해

이 이야기 NYC 2017 droidcon - 클린 응용 프로그램 설계 아키텍처 구성 요소와 함께 그것을 명확히

이 이 그가 간단히 설명 삼촌 밥에서 좋은 비디오 MVC 및 MVP를 말은.

IMO, MVP는 MVC의 개선 된 버전으로 기본적으로 표시 할 내용 (데이터)과 표시 방법 (뷰)을 구분합니다. 발표자에는 UI의 비즈니스 논리가 포함되어 있으며 어떤 데이터를 암시 적으로 표시하고 바보 같은 뷰 모델 목록을 제공합니다. 그리고 데이터를 보여줄 때가되면 뷰 (어쩌면 동일한 ID 포함)를 어댑터에 꽂고 최소한의 코드 만 도입 된 뷰 모델을 사용하여 관련 뷰 필드를 설정하기 만하면됩니다 (세터 만 사용). 주요 이점은 가로 목록 또는 세로 목록에 항목을 표시하는 것과 같이 많은 / 다양한보기에 대해 UI 비즈니스 로직을 테스트 할 수 있다는 것입니다.

MVC에서는 인터페이스 (경계)를 통해 서로 다른 레이어를 접착합니다. 컨트롤러는 아키텍처에 대한 플러그인이지만 표시 할 내용을 적용하는 데 제한이 없습니다. 그런 의미에서 MVP는 어댑터를 통해 컨트롤러에 뷰를 연결할 수있는 개념을 가진 일종의 MVC입니다.

이것이 더 도움이되기를 바랍니다.

ADR ( Action-Domain-Responder)을 잊어 버렸습니다 .

위의 일부 그래픽에서 설명했듯이 MVC 의 모델 과 뷰 사이에는 직접적인 관계 / 링크가 있습니다. 컨트롤러 에서 작업이 수행되고 모델 에서 작업이 실행됩니다 . 에서 그 행동 모델 , 반응 트리거 에서 보기 . 보기는 항상 때 업데이트됩니다 모델 의 상태가 변경됩니다.

어떤 사람들은 MVC 가 70 년대 후반에 만들어 졌다는 것을 계속 잊고 있습니다. " 웹이 80 인치 후반 습니다. MVC는 원래 웹용이 아니라 데스크탑 응용 프로그램 용으로 만들어졌습니다. , 모델과 뷰가 함께 공존합니다.

우리 는 여전히 동일한 명명 규칙 ( model-view-controller ) 을 사용하는 웹 프레임 워크 ( 예 : Laravel )를 사용하기 때문에 MVC 여야한다고 생각하는 경향이 있지만 실제로는 다른 것입니다.

대신 Action-Domain-Responder를 살펴보십시오 . ADR에서 컨트롤러 는 모델 / 도메인 에서 작업을 수행하는 Action을 가져 옵니다 . 지금까지 동일합니다. 차이점은 해당 작업의 응답 / 데이터를 수집 하여 렌더링 을 위해 응답자 ( 예 :. )에게 전달한다는 것 입니다. 동일한 구성 요소에서 새 조치가 요청되면 Controller 가 다시 호출되고주기 자체가 반복됩니다. ADR에서는 모델 / 도메인과보기 ( 응답자 응답 ) 간에 연결 이 없습니다 .view()

참고 : Wikipedia에 " 각 ADR 작업은 별도의 클래스 또는 클로저로 표시됩니다. " 반드시 그런 것은 아닙니다 . 여러 작업이 동일한 컨트롤러에있을 수 있으며 패턴은 여전히 ​​동일합니다.

mvc adr 모델 뷰 컨트롤러 활동 도메인 응답자

가장 간단한 대답은 뷰가 모델과 상호 작용하는 방식입니다. MVP에서 뷰는 발표자에 의해 업데이트되며 뷰와 모델 사이의 중개자 역할을합니다. 발표자는 뷰에서 입력을 가져와 모델에서 데이터를 검색 한 다음 필요한 비즈니스 로직을 수행 한 다음 뷰를 업데이트합니다. MVC에서 모델은 컨트롤러를 거치지 않고 뷰를 직접 업데이트합니다.

• MVC에서 View에는 UI 부분이 있으며 컨트롤러는 view와 model 사이의 중재자이며 비즈니스 모델은 비즈니스 로직을 포함합니다.
• MVP에서보기에는 UI와 발표자의 구현이 모두 포함됩니다. 여기서 발표자는 인터페이스 및 모델이 동일하므로 비즈니스 논리가 포함됩니다.

MVP

MVP는 Model-View- Presenter의 약자입니다. 이것은 2007 년 초에 Microsoft가 Smart Client Windows 응용 프로그램을 도입 한 그림에 대한 것입니다.

발표자는 모델에서 View 이벤트와 비즈니스 로직을 바인딩하는 MVP의 감독 역할을 수행합니다.

View 이벤트 바인딩은 Presenter에서보기 인터페이스에서 구현됩니다.

보기는 사용자 입력의 개시 자이며 이벤트를 발표자에게 위임하고 발표자는 이벤트 바인딩을 처리하고 모델에서 데이터를 가져옵니다.

장점 : 보기에는 로직이 아닌 UI 만 있습니다. 높은 수준의 테스트 가능성

단점 : 이벤트 바인딩을 구현할 때 약간 복잡하고 더 많은 작업

MVC

MVC는 Model-View-Controller를 나타냅니다. Controller는 모델을 작성하고 바인딩 모델을 사용하여 뷰를 렌더링합니다.

Controller는 개시 자이며 렌더링 할보기를 결정합니다.

장점 : 단일 책임 원칙에 대한 강조 높은 수준의 테스트 가능성

단점 : 동일한 컨트롤러에서 여러보기를 렌더링하려는 경우 컨트롤러에 대한 작업량이 너무 많은 경우가 있습니다.