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

질문자 :Mike Minutillo

이 게시물을 개선하고 싶으십니까? 인용 및 귀하의 답변이 정확한 이유에 대한 설명을 포함하여 이 질문에 대한 자세한 답변을 제공하십시오. 내용이 충분하지 않은 답변은 수정 또는 삭제될 수 있습니다.

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

1. 이러한 패턴은 어떤 문제를 해결합니까?
2. 어떻게 비슷합니까?
3. 어떻게 다른가요?

모델-뷰-발표자

MVP 에서 Presenter는 View에 대한 UI 비즈니스 로직을 포함합니다. View의 모든 호출은 Presenter에게 직접 위임됩니다. Presenter는 View에서 직접 분리되어 인터페이스를 통해 통신합니다. 이것은 단위 테스트에서 View의 mock을 허용하기 위한 것입니다. MVP의 공통적인 속성 중 하나는 양방향 디스패치가 많이 있어야 한다는 것입니다. 예를 들어 누군가 "저장" 버튼을 클릭하면 이벤트 처리기가 발표자의 "OnSave" 메서드에 위임합니다. 저장이 완료되면 Presenter는 인터페이스를 통해 View를 다시 호출하여 View에서 저장이 완료되었음을 표시할 수 있습니다.

MVP는 WebForms에서 분리된 프리젠테이션을 달성하기 위한 매우 자연스러운 패턴인 경향이 있습니다. 그 이유는 View가 항상 ASP.NET 런타임에 의해 먼저 생성되기 때문입니다. 두 가지 변형에 대해 자세히 알아볼 수 있습니다.

두 가지 기본 변형

수동적 보기: 보기는 최대한 멍청하고 논리가 거의 없습니다. 발표자는 뷰와 모델과 대화하는 중간 사람입니다. View와 Model은 서로 완전히 보호됩니다. Model은 이벤트를 발생시킬 수 있지만 Presenter는 View를 업데이트하기 위해 이벤트를 구독합니다. Passive View에는 직접적인 데이터 바인딩이 없으며 대신 View는 Presenter가 데이터를 설정하는 데 사용하는 setter 속성을 노출합니다. 모든 상태는 View가 아닌 Presenter에서 관리됩니다.

• 장점: 최대 테스트 가능성 표면; View와 Model의 깔끔한 분리
• 단점: 모든 데이터 바인딩을 직접 수행하므로 더 많은 작업(예: 모든 setter 속성)이 필요합니다.

감독 컨트롤러: 발표자는 사용자 제스처를 처리합니다. View는 데이터 바인딩을 통해 모델에 직접 바인딩됩니다. 이 경우 모델이 바인딩될 수 있도록 뷰에 모델을 전달하는 것이 발표자의 작업입니다. Presenter에는 버튼 누르기, 탐색 등과 같은 제스처에 대한 논리도 포함됩니다.

• 장점: 데이터 바인딩을 활용하면 코드 양이 줄어듭니다.
• 단점: (데이터 바인딩으로 인해) 테스트 가능한 표면이 덜하고 View가 Model과 직접 통신하기 때문에 View에서 캡슐화가 적습니다.

모델-뷰-컨트롤러

MVC 에서 컨트롤러는 애플리케이션이 로드될 때를 포함하여 모든 작업에 대한 응답으로 표시할 보기를 결정하는 역할을 합니다. 이는 작업이 보기를 통해 발표자에게 전달되는 MVP와 다릅니다. MVC에서 보기의 모든 작업은 작업과 함께 컨트롤러에 대한 호출과 관련이 있습니다. 웹에서 각 작업에는 응답하는 컨트롤러가 있는 다른 쪽의 URL에 대한 호출이 포함됩니다. 컨트롤러가 처리를 완료하면 올바른 보기를 반환합니다. 시퀀스는 응용 프로그램의 수명 동안 다음과 같은 방식으로 계속됩니다.

    보기의 작업
        -> 컨트롤러 호출
        -> 컨트롤러 로직
        -> 컨트롤러가 보기를 반환합니다.

MVC의 또 다른 큰 차이점은 View가 Model에 직접 바인딩되지 않는다는 것입니다. 보기는 단순히 렌더링되고 완전히 상태 비저장입니다. MVC 구현에서 View는 일반적으로 코드 뒤에 논리가 없습니다. 이는 View가 Presenter에게 위임하지 않으면 절대 호출되지 않기 때문에 절대적으로 필요한 MVP와 반대입니다.

프레젠테이션 모델

살펴볼 또 다른 패턴은 프레젠테이션 모델 패턴입니다. 이 패턴에는 발표자가 없습니다. 대신 View는 Presentation Model에 직접 바인딩됩니다. 프레젠테이션 모델은 뷰를 위해 특별히 제작된 모델입니다. 이는 이 모델이 관심 분리를 위반하므로 도메인 모델에 적용하지 않을 속성을 노출할 수 있음을 의미합니다. 이 경우 프레젠테이션 모델은 도메인 모델에 바인딩되고 해당 모델에서 오는 이벤트를 구독할 수 있습니다. 그런 다음 보기는 프레젠테이션 모델에서 오는 이벤트를 구독하고 그에 따라 자체 업데이트합니다. 프레젠테이션 모델은 뷰가 작업을 호출하는 데 사용하는 명령을 노출할 수 있습니다. 이 접근 방식의 장점은 PM이 뷰에 대한 모든 동작을 완전히 캡슐화하므로 코드 숨김을 근본적으로 완전히 제거할 수 있다는 것입니다. 이 패턴은 WPF 응용 프로그램에서 사용할 수 있는 매우 강력한 후보이며 Model-View-ViewModel 이라고도 합니다.

프레젠테이션 모델에 대한 MSDN 기사 와 분리된 프레젠테이션 패턴 에 대한 WPF(이전 Prism) 용 복합 응용 프로그램 지침 섹션이 있습니다.

Community Wiki

이것은 이러한 디자인 패턴의 많은 변형을 지나치게 단순화한 것입니다.

MVC

MVP

Phyxx

얼마 전에 Todd Snyder의 두 가지 차이점에 대한 훌륭한 게시물을 인용하여 이에 대해 블로그에 글을 남겼습니다.

다음은 패턴 간의 주요 차이점입니다.

MVP 패턴

• 보기는 모델에 더 느슨하게 결합됩니다. 프리젠터는 모델을 뷰에 바인딩할 책임이 있습니다.
• 보기와의 상호 작용이 인터페이스를 통해 이루어지기 때문에 단위 테스트가 더 쉽습니다.
• 일반적으로 발표자 지도를 일대일로 봅니다. 복잡한 보기에는 여러 발표자가 있을 수 있습니다.

MVC 패턴

• 컨트롤러는 동작을 기반으로 하며 뷰 간에 공유할 수 있습니다.
• 표시할 보기를 결정하는 역할을 할 수 있습니다.

내가 찾을 수있는 웹에서 가장 좋은 설명입니다.

Jon Limjap

다음은 통신 흐름을 나타내는 그림입니다.

Ashraf Bashir

MVP가 반드시 View가 책임지는 시나리오는 아닙니다 (예를 들어 Taligent의 MVP 참조).
"그냥 보기일 뿐입니다"(실용적인 프로그래머)와 모순되는 안티패턴이 아닌 패턴(보기 담당관)으로 설교하는 사람들이 여전히 많다는 것이 안타까운 일입니다. "그것은 단지 보기일 뿐입니다"는 사용자에게 표시되는 최종 보기가 애플리케이션의 부차적인 관심사임을 나타냅니다. Microsoft의 MVP 패턴은 Views의 재사용을 훨씬 더 어렵게 만들고 Microsoft 디자이너가 나쁜 습관을 조장하는 것을 편리하게 변명합니다.

솔직히 말해서 MVC의 근본적인 우려는 모든 MVP 구현에 적용되며 차이점은 거의 완전히 의미론적이라고 생각합니다. 뷰(데이터를 표시하는), 컨트롤러(사용자 상호 작용을 초기화하고 제어하는) 및 모델(기본 데이터 및/또는 서비스) 사이의 관심사를 분리하는 한 MVC의 이점을 얻을 수 있습니다. . 혜택을 얻고 있다면 누가 당신의 패턴이 MVC, MVP 또는 감독 컨트롤러인지 여부를 정말로 신경 쓰나요? 유일한 실제 패턴은 MVC로 남아 있고 나머지는 다른 맛일 뿐입니다.

고려 이 종합적으로 이러한 서로 다른 구현의 수를 나열 매우 흥미로운 기사를. 당신은 그들이 모두 기본적으로 같은 일을 하지만 약간 다르게 하고 있다는 것을 알 수 있습니다.

저는 개인적으로 MVP가 진정한 MVC인지 아닌지를 주장하는 의미론적 편협한 사람들 사이의 논쟁을 줄이거나 Microsoft의 빠른 응용 프로그램 개발 도구를 정당화하기 위해 최근에야 눈에 띄는 용어로 다시 도입되었다고 생각합니다. 내 책에서 이러한 이유 중 어느 것도 별도의 디자인 패턴으로 존재를 정당화하지 않습니다.

Quibblesome

MVP: 뷰가 담당합니다.

대부분의 경우 보기는 발표자를 만듭니다. 발표자는 모델과 상호 작용하고 인터페이스를 통해 보기를 조작합니다. 보기는 일반적으로 일부 인터페이스를 통해 발표자와 상호 작용하는 경우가 있습니다. 이것은 구현에 달려 있습니다. 보기가 발표자의 메서드를 호출하도록 하시겠습니까? 아니면 보기에서 발표자가 수신하는 이벤트를 듣게 하시겠습니까? 요약하자면 뷰는 발표자에 대해 알고 있습니다. 보기는 발표자에게 위임됩니다.

MVC: 컨트롤러가 담당합니다.

컨트롤러는 일부 이벤트/요청을 기반으로 생성되거나 액세스됩니다. 그런 다음 컨트롤러는 적절한 보기를 만들고 모델과 상호 작용하여 보기를 추가로 구성합니다. 컨트롤러는 뷰를 생성하고 관리합니다. 뷰는 컨트롤러의 슬레이브입니다. 뷰는 컨트롤러에 대해 알지 못합니다.

Brian Leahy

MVC(모델 뷰 컨트롤러)

입력은 보기가 아닌 컨트롤러로 먼저 전달됩니다. 그 입력은 페이지와 상호 작용하는 사용자로부터 올 수도 있지만 단순히 특정 URL을 브라우저에 입력하는 것일 수도 있습니다. 두 경우 모두 일부 기능을 시작하기 위해 인터페이스되는 컨트롤러입니다. Controller와 View 사이에는 다대일 관계가 있습니다. 단일 컨트롤러가 실행 중인 작업에 따라 렌더링할 다른 보기를 선택할 수 있기 때문입니다. Controller에서 View로 가는 단방향 화살표에 유의하십시오. 이는 View에 컨트롤러에 대한 지식이나 참조가 없기 때문입니다. 컨트롤러는 모델을 다시 전달하므로 뷰와 여기에 전달되는 예상 모델 사이에 정보가 있지만 이를 제공하는 컨트롤러는 아닙니다.

MVP(모델 뷰 발표자)

입력은 발표자가 아니라 보기로 시작합니다. View와 연결된 Presenter 사이에는 일대일 매핑이 있습니다. 보기는 발표자에 대한 참조를 보유합니다. Presenter는 View에서 트리거되는 이벤트에도 반응하므로 연결된 View를 인식합니다. Presenter는 Model에서 수행하는 요청된 작업을 기반으로 View를 업데이트하지만 View는 Model을 인식하지 못합니다.

더 많은 참조를 위해

AVI

질문에 대한 답은 여러 가지가 있지만 둘을 명확하게 비교하는 정말 간단한 답이 필요하다고 느꼈습니다. 다음은 사용자가 MVP 및 MVC 앱에서 영화 이름을 검색할 때 만든 토론입니다.

사용자: 클릭 클릭 …

보기 : 누구세요? [ MVP | MVC ]

사용자: 방금 검색 버튼을 눌렀습니다...

보기 : 알겠습니다. 잠시만요. . . . [ MVP | MVC ]

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

보기 : 안녕하세요 발표자 | 컨트롤러 , 사용자가 방금 검색 버튼을 클릭했습니다. 어떻게 해야 합니까? [ MVP | MVC ]

발표자 | 컨트롤러 : Hey View , 그 페이지에 검색어가 있습니까? [ MVP | MVC ]

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

발표자 | Controller : Thank You View ,… 그동안 모델 에서 검색어를 찾는 중입니다. 진행률 표시줄을 보여주세요. [ MVP | MVC ]

( 발표자 | 컨트롤러 가 모델을 호출하고 있습니다 ... ) [ MVP | MVC ]

발표자 | 컨트롤러 : Hey Model , 이 검색어와 일치하는 항목이 있습니까?: "piano" [ MVP | MVC ]

모델 : 안녕하세요 발표자 | 컨트롤러 , 확인하겠습니다... [ MVP | MVC ]

( 모델 이 영화 데이터베이스에 질의를 하고 있다… ) [ MVP | MVC ]

( 잠시 후 ... )

-------------- 여기에서 MVP와 MVC가 갈라지기 시작합니다 ---------------

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

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

( 발표자 | 컨트롤러 는 모델 에게 감사를 표하고 뷰로 돌아갑니다 ) [ MVP | MVC ]

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

Controller : View 를 기다려 주셔서 감사 합니다. Model 에게 귀하의 검색어에 대해 문의했습니다. 일치하는 결과 목록을 찾아 해당 인스턴스 내부의 "searchResultsList"라는 변수에 저장했다고 말합니다. 거기에서 얻을 수 있습니다. 또한 지금 진행률 표시줄을 숨기십시오 [ MVC ]

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

View : "Controller" [ MVC ] 감사합니다. (이제 View 는 스스로에게 질문을 하고 있습니다. Model 에서 얻은 결과를 사용자에게 어떻게 제시해야 할까요? 영화의 제작 연도가 먼저 와야 할까요 아니면 마지막에 와야 할까요...? 세로 또는 가로 목록에 있습니까? ...)

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

Ali Nem

모델-뷰-컨트롤러

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

• 데이터 및 비즈니스 로직을 처리하기 위한 모델
• 사용자 인터페이스 및 애플리케이션을 처리하기 위한 컨트롤러
• 그래픽 사용자 인터페이스 개체 및 프레젠테이션을 처리하기 위한 보기

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

모델-뷰-발표자

• 모델 은 보기(사용자 인터페이스)에 표시될 데이터입니다.
• 보기 는 데이터(모델)를 표시하고 사용자 명령(이벤트)을 발표자에게 라우팅하여 해당 데이터에 대한 작업을 수행하는 인터페이스입니다. 보기에는 일반적으로 발표자에 대한 참조가 있습니다.
• 발표자 는 "중간자"(MVC에서 컨트롤러가 담당)이며 보기와 모델 모두에 대한 참조가 있습니다. "모델"이라는 단어 는 오해의 소지가 있습니다. Model 을 검색하거나 조작하는 비즈니스 로직 이어야 합니다. 예: 데이터베이스 테이블에 User를 저장하는 데이터베이스가 있고 View에서 사용자 목록을 표시하려는 경우 Presenter는 Presenter가 목록을 쿼리하는 DAO와 같은 데이터베이스 비즈니스 논리에 대한 참조를 갖게 됩니다. 사용자의.

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

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

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

MVC 패턴

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

• 표시할 보기를 결정하는 역할을 할 수 있습니다(전면 컨트롤러 패턴).

MVP 패턴

• 보기는 모델에 더 느슨하게 결합됩니다. 프리젠터는 모델을 뷰에 바인딩할 책임이 있습니다.

• 보기와의 상호 작용이 인터페이스를 통해 이루어지기 때문에 단위 테스트가 더 쉽습니다.

• 일반적으로 발표자 지도를 일대일로 봅니다. 복잡한 보기에는 여러 발표자가 있을 수 있습니다.

Rahul

• MVP = 모델-뷰-발표자

• MVC = 모델-뷰-컨트롤러

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

Brett Veenstra

또한 다양한 유형의 MVP도 있다는 점을 기억할 가치가 있습니다. Fowler는 패시브 뷰와 감독 컨트롤러의 두 가지로 패턴을 나누었습니다.

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

구현은 다음과 같을 수 있습니다.

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

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

MVP의 두 번째 특징은 감독 컨트롤러입니다. 이 경우 뷰에 Customer라는 속성이 있을 수 있으며 이 속성은 다시 UI 위젯에 데이터 바인딩됩니다. 보기를 동기화하고 미세하게 관리하는 것에 대해 생각할 필요가 없으며 감독 컨트롤러가 예를 들어 완성된 상호 작용 논리와 같이 필요할 때 개입하여 도움을 줄 수 있습니다.

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

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

나는 또한 YouCard Re-visited: Implementing the ViewModel 패턴 에서 Silverlight의 맥락에서 Model-View-ViewModel 패턴에 대해 블로그를 작성했습니다.

Jonas Follesø

이 두 프레임워크는 데이터 소스(모델), 애플리케이션 로직(또는 이 데이터를 유용한 정보로 전환)(컨트롤러/프레젠터) 및 디스플레이 코드(보기)와의 상호 작용과 같은 별도의 관심사를 목표로 합니다. 어떤 경우에는 모델을 사용하여 데이터 소스를 더 높은 수준의 추상화로 전환할 수도 있습니다. 이에 대한 좋은 예는 MVC Storefront 프로젝트 입니다.

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

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

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

그렇긴 하지만 ASP.NET MVC는 이러한 정의에 따라 MVP 프레임워크입니다. 컨트롤러가 모델에 액세스하여 논리가 없는 뷰를 채우기 때문입니다(컨트롤러에서 제공하는 변수만 표시함).

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

Matt Mitchell

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

구조적으로 MVP는 페이지 컨트롤러 기반 접근 방식이고 MVC는 전면 컨트롤러 기반 접근 방식입니다. 즉, MVP 표준 웹 양식 페이지 수명 주기는 코드 숨김에서 비즈니스 논리를 추출하여 향상됩니다. 즉, 페이지는 http 요청을 처리하는 페이지입니다. 즉, MVP IMHO는 웹 형태의 진화형 향상 유형입니다. 반면에 MVC는 페이지가 로드되기 전에 컨트롤러 클래스에 의해 요청이 가로채기 때문에 게임이 완전히 변경되고 비즈니스 로직이 그곳에서 실행된 다음 컨트롤러가 페이지에 방금 덤프한 데이터를 처리한 결과("보기")에서 센스, MVC는 라우팅 엔진으로 강화된 MVP의 감독 컨트롤러 풍미를 (적어도 나에게는) 많이 봅니다.

둘 다 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

Nikola Malovic

저는 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

Pedro Santos

MVP에서 뷰는 모델에서 데이터를 그리고 준비/정규화하는 발표자로부터 데이터를 가져오는 반면 MVC에서는 컨트롤러가 뷰에서 푸시하여 모델 및 설정에서 데이터를 끌어옵니다.

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

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

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

따라서 예를 들어 모델이 자동차인 경우 발표자는 일종의 자동차 발표자이며 자동차 속성(연도, 제조업체, 좌석 등)을 뷰에 노출합니다. 뷰는 'car maker'라는 텍스트 필드가 Presenter Maker 속성을 표시해야 한다는 것을 알고 있습니다.

그런 다음 보기에 다양한 유형의 발표자를 바인딩할 수 있습니다. 모두 Maker 속성이 있어야 합니다. 비행기, 기차 또는 무엇이든 상관없습니다. 보기는 상관하지 않습니다. 보기는 합의된 인터페이스를 구현하는 한 발표자로부터 데이터를 가져옵니다.

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

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

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

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

James Roeiter

저의 겸손한 짧은 견해: MVP는 대규모용이고 MVC는 소규모용입니다. MVC를 사용하면 V와 C가 M에 직접 바인딩되기보다는 분할할 수 없는 단일 구성 요소의 양면으로 보일 수 있으며 UI 컨트롤 및 기본 위젯과 같이 더 짧은 축척으로 이동할 때 필연적으로 한쪽이 여기에 빠지게 됩니다. 이 세분성 수준에서 MVP는 거의 의미가 없습니다. 반대로 하나가 더 큰 규모로 갈 때 적절한 인터페이스가 더 중요해지고 명확한 책임 할당과 마찬가지로 여기에 MVP가 있습니다.

반면에, 플랫폼 특성이 MVP보다 MVC를 구현하는 것이 더 쉬운 웹과 같이 구성 요소 간의 어떤 종류의 관계를 선호하는 경우 이 경험적 척도 규칙은 거의 중요하지 않을 수 있습니다.

Hibou57

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

(이 기사 는 또한 그의 연설 중 하나에서 Bob Martin 삼촌이 말한 것과 일치합니다. MVC는 원래 시스템 아키텍처가 아니라 작은 UI 구성요소를 위해 설계되었습니다.)

Jeremiah Flaga

MVC에는 여러 버전이 있습니다. 이 답변은 Smalltalk의 원래 MVC에 대한 것입니다. 요컨대, 그것은

이 토크 droidcon NYC 2017 - 아키텍처 구성 요소를 사용한 깔끔한 앱 디자인은 그것을 명확히 합니다.

onmyway133

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

Clive Jefferies

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

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

MVC에서는 인터페이스(경계)를 통해 서로 다른 레이어를 연결합니다. 컨트롤러는 우리 아키텍처의 플러그인이지만 무엇을 보여줄 것인지에 대한 제한이 없습니다. 그런 의미에서 MVP는 어댑터를 통해 컨트롤러에 연결할 수 있는 뷰의 개념을 가진 일종의 MVC입니다.

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

stdout

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

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

어떤 사람들은 MVC가 70" 후반에 만들어졌고 웹이 80"/90" 초반에만 만들어졌다는 사실을 계속 잊고 있습니다. MVC는 원래 웹용이 아니라 데스크탑 응용 프로그램용으로 만들어졌습니다. , Model과 View는 함께 공존할 것입니다.

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

대신 Action-Domain-Responder를 살펴보십시오. ADR에서 컨트롤러 는 Model/Domain 에서 작업을 수행하는 Action을 얻습니다. 지금까지는 동일합니다. 차이점은 그런 다음 해당 작업의 응답/데이터를 수집하고 렌더링을 위해 응답자 ( 예:. view() )에 전달한다는 것입니다. 동일한 구성 요소에서 새 작업이 요청되면 컨트롤러 가 다시 호출되고 주기가 반복됩니다. ADR에서는 Model/Domain과 View( Reponser의 응답 ) 사이에 연결이 없습니다.

참고: Wikipedia에서는 " 각 ADR 작업은 개별 클래스 또는 클로저로 표시됩니다. "라고 명시되어 있습니다. 이것은 반드시 사실 은 아닙니다. 여러 작업이 동일한 컨트롤러에 있을 수 있으며 패턴은 여전히 동일합니다.

mvc adr 모델 보기 컨트롤러 작업 도메인 응답기

Hugo Rafael Azevedo

몇 마디로,

• MVC에서 View에는 컨트롤러를 호출하는 UI 부분이 있으며, 컨트롤러는 차례로 모델 및 모델을 호출하고 이벤트를 다시 보기로 실행합니다.
• MVP에서 View는 UI를 포함하고 구현 부분을 위해 Presenter를 호출합니다. 발표자는 UI 부분에 대한 업데이트를 위해 뷰를 직접 호출합니다. 비즈니스 로직을 포함하는 모델은 발표자에 의해 호출되며 뷰와의 상호 작용은 없습니다. 따라서 여기에서 발표자가 대부분의 작업을 수행합니다. :)

Chinmai Kulkarni

MVP

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

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

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

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

장점: 뷰가 로직이 아닌 UI만 있음 높은 수준의 테스트 용이성

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

MVC

MVC는 Model-View-Controller의 약자입니다. 컨트롤러는 모델을 만들고 바인딩 모델을 사용하여 뷰를 렌더링하는 역할을 합니다.

컨트롤러는 개시자이며 렌더링할 보기를 결정합니다.

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

단점: 동일한 컨트롤러에서 여러 보기를 렌더링하려고 하면 때때로 컨트롤러에 너무 많은 작업 부하가 발생합니다.

marvelTracker

출처 : http:www.stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference