MVP와 MVC는 무엇이며 차이점은 무엇입니까?
https://stackoverflow.com/questions/2056
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian해결책
모델-뷰-발표자
~ 안에 MVP, Presenter에는 뷰에 대한 UI 비즈니스 로직이 포함되어 있습니다.View 대리자의 모든 호출은 Presenter로 직접 전달됩니다.Presenter는 View에서 직접 분리되어 인터페이스를 통해 대화합니다.이는 단위 테스트에서 뷰를 조롱할 수 있도록 하기 위한 것입니다.MVP의 일반적인 특성 중 하나는 양방향 파견이 많아야 한다는 것입니다.예를 들어, 누군가가 "Save" 버튼을 클릭하면 이벤트 핸들러는 Presenter의 "OnSave" 메서드에 위임합니다.저장이 완료되면 Presenter는 인터페이스를 통해 View를 다시 호출하여 View에서 저장이 완료되었음을 표시할 수 있습니다.
MVP는 Web Forms에서 분리된 프레젠테이션을 달성하기 위한 매우 자연스러운 패턴인 경향이 있습니다.그 이유는 뷰가 항상 ASP.NET 런타임에 의해 먼저 생성되기 때문입니다.당신은 할 수 있습니다 두 변형에 대해 자세히 알아보세요..
두 가지 기본 변형
패시브 뷰: 뷰는 가능한 한 멍청하고 논리가 거의 없습니다.Presenter는 View와 Model과 대화하는 중개자입니다.뷰와 모델은 서로 완전히 보호됩니다.모델은 이벤트를 발생시킬 수 있지만 발표자는 뷰 업데이트를 위해 이를 구독합니다.Passive View에는 직접적인 데이터 바인딩이 없습니다. 대신 View는 Presenter가 데이터를 설정하는 데 사용하는 setter 속성을 노출합니다.모든 상태는 뷰가 아닌 프레젠터에서 관리됩니다.
- 찬성:최대 테스트 가능성 표면;뷰와 모델을 깔끔하게 분리
- 범죄자:모든 데이터 바인딩을 직접 수행하므로 더 많은 작업(예: 모든 setter 속성)이 수행됩니다.
감독 컨트롤러: Presenter는 사용자 제스처를 처리합니다.뷰는 데이터 바인딩을 통해 모델에 직접 바인딩됩니다.이 경우 모델이 뷰에 바인딩될 수 있도록 모델을 뷰에 전달하는 것이 Presenter의 임무입니다.Presenter에는 버튼 누르기, 탐색 등과 같은 제스처에 대한 논리도 포함됩니다.
- 찬성:데이터바인딩을 활용하면 코드의 양이 줄어듭니다.
- 범죄자:데이터 바인딩으로 인해 테스트 가능한 표면이 적고, 모델과 직접 통신하기 때문에 뷰의 캡슐화가 적습니다.
모델-뷰-컨트롤러
에서 MVC, 컨트롤러는 애플리케이션이 로드되는 시기를 포함하여 모든 작업에 대한 응답으로 표시할 보기를 결정하는 역할을 담당합니다.이는 작업이 보기를 통해 발표자에게 전달되는 MVP와 다릅니다.MVC에서 뷰의 모든 작업은 작업과 함께 컨트롤러 호출과 연관됩니다.웹에서 각 작업에는 응답하는 컨트롤러가 있는 반대편의 URL에 대한 호출이 포함됩니다.컨트롤러가 처리를 완료하면 올바른 뷰가 반환됩니다.이 순서는 애플리케이션 수명 내내 다음과 같은 방식으로 계속됩니다.
Action in the View
-> Call to Controller
-> Controller Logic
-> Controller returns the View.
MVC의 또 다른 큰 차이점은 뷰가 모델에 직접 바인딩되지 않는다는 것입니다.뷰는 단순히 렌더링되며 완전히 상태 비저장입니다.MVC 구현에서 뷰는 일반적으로 코드 뒤에 논리가 없습니다.이는 뷰가 프레젠터에게 위임되지 않으면 절대 호출되지 않기 때문에 절대적으로 필요한 MVP와 반대됩니다.
프리젠테이션 모델
살펴봐야 할 또 다른 패턴은 다음과 같습니다. 프리젠테이션 모델 무늬.이 패턴에는 Presenter가 없습니다.대신 뷰는 프레젠테이션 모델에 직접 바인딩됩니다.프리젠테이션 모델은 뷰를 위해 특별히 제작된 모델입니다.이는 이 모델이 관심 분리를 위반하므로 도메인 모델에 결코 적용하지 않을 속성을 노출할 수 있음을 의미합니다.이 경우 프레젠테이션 모델은 도메인 모델에 바인딩되고 해당 모델에서 오는 이벤트를 구독할 수 있습니다.그런 다음 뷰는 프레젠테이션 모델에서 오는 이벤트를 구독하고 그에 따라 자체 업데이트합니다.프레젠테이션 모델은 뷰가 작업을 호출하는 데 사용하는 명령을 노출할 수 있습니다.이 접근 방식의 장점은 PM이 뷰에 대한 모든 동작을 완전히 캡슐화하므로 본질적으로 코드 숨김을 완전히 제거할 수 있다는 것입니다.이 패턴은 WPF 애플리케이션에서 사용할 수 있는 매우 강력한 후보이며 라고도 합니다. 모델-뷰-뷰모델.
이있다 프레젠테이션 모델에 대한 MSDN 기사 그리고 WPF에 대한 복합 애플리케이션 지침 (구 프리즘) 소개 분리된 프레젠테이션 패턴
다른 팁
이는 이러한 디자인 패턴의 다양한 변형을 지나치게 단순화한 것이지만, 이것이 내가 둘 사이의 차이점에 대해 생각하는 방식입니다.
MVC
MVP
나는 이것에 대해 얼마 전에 블로그에 인용했습니다. 둘 사이의 차이점에 대한 Todd Snyder의 훌륭한 게시물:
패턴 간의 주요 차이점은 다음과 같습니다.
MVP 패턴
- 뷰는 모델과 더 느슨하게 결합됩니다.발표자는 모델을보기에 바인딩 할 책임이 있습니다.
- 보기와의 상호 작용이 인터페이스를 통한 것이기 때문에 장치 테스트가 더 쉽습니다.
- 일반적으로 발표자 지도를 일대일로 봅니다.복잡한 견해에는 다수의 발표자가있을 수 있습니다.
MVC 패턴
- 컨트롤러는 동작을 기반으로하며 관점에서 공유 할 수 있습니다.
- 표시할 뷰를 결정하는 역할을 담당할 수 있습니다.
내가 찾은 웹에서 가장 좋은 설명입니다.
다음은 통신 흐름을 나타내는 그림입니다.
MVP는 ~ 아니다 반드시 뷰가 담당하는 시나리오입니다(예를 들어 Taligent의 MVP 참조).
사람들이 여전히 이것을 안티 패턴이 아닌 패턴(담당 보기)으로 설교하는 것은 불행한 일입니다. 이는 "그냥 보기일 뿐"(Pragmatic Programmer)과 모순되기 때문입니다."It's just a view"는 사용자에게 표시되는 최종 보기가 애플리케이션의 부차적인 관심사임을 나타냅니다.Microsoft의 MVP 패턴은 뷰의 재사용을 훨씬 더 어렵게 만들고 편리하게 Microsoft의 디자이너가 나쁜 관행을 조장하는 것을 변명합니다.
솔직히 말해서 MVC의 근본적인 우려 사항은 모든 MVP 구현에 적용되며 차이점은 거의 전적으로 의미적입니다.뷰(데이터를 표시하는), 컨트롤러(사용자 상호 작용을 초기화하고 제어하는) 및 모델(기본 데이터 및/또는 서비스) 간의 우려 사항을 분리하는 한 MVC의 이점을 얻을 수 있습니다. .이점을 얻고 있다면 패턴이 MVC인지, MVP인지, 감독 컨트롤러인지 누가 신경 쓰나요?유일한 진짜 패턴은 MVC로 남아 있고 나머지는 단지 그것의 맛이 다릅니다.
고려하다 이것 이러한 다양한 구현을 포괄적으로 나열하는 매우 흥미로운 기사입니다.기본적으로 모두 동일한 작업을 수행하지만 약간씩 다르다는 점을 알 수 있습니다.
개인적으로 MVP는 무언가가 진정한 MVC인지 아닌지를 논쟁하는 의미론적 편견 사이의 논쟁을 줄이거나 Microsoft의 신속한 애플리케이션 개발 도구를 정당화하기 위해 최근에야 눈길을 끄는 용어로 다시 도입되었다고 생각합니다.내 책에 나오는 이러한 이유 중 어느 것도 별도의 디자인 패턴으로서의 존재를 정당화하지 못합니다.
MVP:보기가 담당합니다.
대부분의 경우 뷰는 프리젠터를 생성합니다.발표자는 모델과 상호 작용하고 인터페이스를 통해 뷰를 조작합니다.뷰는 일반적으로 일부 인터페이스를 통해 발표자와 상호 작용하는 경우가 있습니다.이는 구현으로 귀결됩니다.뷰가 발표자의 메서드를 호출하도록 하시겠습니까, 아니면 뷰에 발표자가 듣는 이벤트가 포함되도록 하시겠습니까?이는 다음과 같이 요약됩니다.뷰는 발표자에 대해 알고 있습니다.뷰는 발표자에게 위임됩니다.
MVC:컨트롤러가 담당합니다.
컨트롤러는 일부 이벤트/요청에 따라 생성되거나 액세스됩니다.그런 다음 컨트롤러는 적절한 뷰를 생성하고 모델과 상호 작용하여 뷰를 추가로 구성합니다.그것은 다음과 같이 요약됩니다:컨트롤러는 뷰를 생성하고 관리합니다.뷰는 컨트롤러의 슬레이브입니다.뷰는 컨트롤러에 대해 알지 못합니다.
MVC(모델 뷰 컨트롤러)
입력은 뷰가 아닌 컨트롤러로 먼저 전달됩니다.해당 입력은 페이지와 상호 작용하는 사용자로부터 나올 수도 있지만 단순히 브라우저에 특정 URL을 입력하는 것에서 나올 수도 있습니다.두 경우 모두 일부 기능을 시작하기 위해 인터페이스되는 컨트롤러입니다.Controller와 View 사이에는 다대일 관계가 있습니다.이는 단일 컨트롤러가 실행 중인 작업에 따라 렌더링할 다른 뷰를 선택할 수 있기 때문입니다.컨트롤러에서 뷰로 향하는 단방향 화살표에 유의하세요.이는 뷰가 컨트롤러에 대한 지식이나 참조를 갖고 있지 않기 때문입니다.컨트롤러는 모델을 다시 전달하므로 뷰와 전달되는 예상 모델 사이에는 지식이 있지만 컨트롤러는 모델을 제공하지 않습니다.
MVP(모델 뷰 프리젠터)
입력은 Presenter가 아닌 View로 시작됩니다.View와 관련 Presenter 사이에는 일대일 매핑이 있습니다.뷰는 발표자에 대한 참조를 보유합니다.Presenter는 View에서 트리거되는 이벤트에도 반응하므로 연결된 View를 인식합니다.Presenter는 모델에서 수행하는 요청된 작업을 기반으로 View를 업데이트하지만 View는 모델을 인식하지 못합니다.
이상 참조
질문에 대한 답변은 많지만, 그 둘을 명확하게 비교하는 정말 간단한 답변이 필요하다고 느꼈습니다.사용자가 MVP 및 MVC 앱에서 영화 이름을 검색할 때 제가 작성한 토론은 다음과 같습니다.
사용자:클릭클릭…
보다:누구야?[MVP|MVC]
사용자:방금 검색버튼을 눌렀는데...
보다:알았어, 잠깐만…[MVP|MVC]
( 보다 전화 증여자|제어 장치 … ) [MVP|MVC]
보다:여기요 증여자|제어 장치, 사용자가 방금 검색 버튼을 클릭했습니다. 어떻게 해야 합니까?[MVP|MVC]
증여자|제어 장치:여기요 보다, 해당 페이지에 검색어가 있나요?[MVP|MVC]
보다:네... 여기 있습니다... "피아노" [MVP|MVC]
증여자:감사해요 보다,… 그러는 동안 저는 검색어를 검색하고 있습니다. 모델, 진행률 표시줄을 보여주세요 [MVP|MVC]
( 증여자|제어 장치 전화하고있다 모델 … ) [MVP|MVC]
증여자|제어 장치:여기요 모델, 이 검색어와 일치하는 항목이 있습니까?:“피아노” [MVP|MVC]
모델:여기요 증여자|제어 장치, 내가 체크해 볼게 … [MVP|MVC]
( 모델 영화 데이터베이스에 쿼리를 보내고 있습니다… ) [MVP|MVC]
( 잠시 후 ...)
-------------- 이것이 MVP와 MVC가 갈라지기 시작하는 지점입니다 ---------------
모델:당신을 위한 목록을 찾았습니다. 증여자, 여기 JSON에 있습니다. “[{"name":"Piano Teacher","year":2001},{"name":"Piano","year":1993}]” [MVP]
모델:사용할 수 있는 결과가 있습니다. 제어 장치.내 인스턴스에 필드 변수를 만들고 그 결과를 채웠습니다.이름은 "searchResultsList"입니다.MVC]
(증여자|제어 장치 감사해요 모델 그리고 다시 돌아옵니다 보다) [MVP|MVC]
증여자:기다려 줘서 고마워요 보다, 귀하에게 일치하는 결과 목록을 찾아 보기 쉬운 형식으로 정리했습니다.["피아노 선생님 2001","피아노 1993"].세로 목록으로 사용자에게 보여주세요.또한 지금 진행률 표시줄을 숨겨주세요. [MVP]
제어 장치:기다려 줘서 고마워요 보다, 나는 물어 보았다 모델 귀하의 검색어에 대해일치하는 결과 목록을 찾아 인스턴스 내부의 "searchResultsList"라는 변수에 저장했다고 합니다.거기에서 얻을 수 있습니다.또한 지금 진행률 표시줄을 숨겨주세요. [MVC]
보다:매우 감사합니다 증여자 [MVP]
보다:감사합니다 "컨트롤러" [MVC] (이제 보다 스스로에게 질문하고 있습니다.내가 얻은 결과를 어떻게 발표해야합니까? 모델 사용자에게?영화 제작 연도가 먼저 와야 할까요, 아니면 마지막에 와야 할까요...?수직 또는 수평 목록에 있어야 합니까?...)
관심이 있으신 경우를 대비해 저는 Github 저장소와 함께 앱 아키텍처 패턴(MVC, MVP, MVVP, 클린 아키텍처 등)을 다루는 일련의 기사를 작성해 왔습니다. 여기.샘플은 Android용으로 작성되었지만 기본 원칙은 모든 매체에 적용될 수 있습니다.
- MVP = 모델-뷰-발표자
MVC = 모델-뷰-컨트롤러
- 두 가지 프레젠테이션 패턴 모두.모델(도메인 객체 생각), 화면/웹 페이지(뷰), UI 작동 방식(발표자/컨트롤러) 간의 종속성을 분리합니다.
- 그들은 개념상 상당히 유사하며, 사람들은 취향에 따라 발표자/컨트롤러를 다르게 초기화합니다.
- 차이점에 대한 훌륭한 기사는 다음과 같습니다. 여기.가장 주목할만한 점은 MVC 패턴에는 뷰를 업데이트하는 모델이 있다는 것입니다.
또한 기억할 가치가 있는 점은 MVP에도 다양한 유형이 있다는 것입니다.Fowler는 패턴을 Passive View와 Supervising Controller의 두 가지로 나누었습니다.
패시브 뷰를 사용하는 경우 뷰는 일반적으로 기본 UI 위젯에 직접 매핑되는 속성을 사용하여 세분화된 인터페이스를 구현합니다.예를 들어 이름 및 주소와 같은 속성이 있는 ICustomerView가 있을 수 있습니다.
구현은 다음과 같을 수 있습니다.
public class CustomerView : ICustomerView
{
public string Name
{
get { return txtName.Text; }
set { txtName.Text = value; }
}
}
Presenter 클래스는 모델과 대화하고 이를 뷰에 "매핑"합니다.이 접근 방식을 "수동 보기"라고 합니다.장점은 뷰를 테스트하기 쉽고 UI 플랫폼(웹, Windows/XAML 등) 간에 이동하기가 더 쉽다는 것입니다.단점은 데이터 바인딩과 같은 기능을 활용할 수 없다는 것입니다. 정말 다음과 같은 프레임워크에서 강력합니다. WPF 그리고 실버라이트).
MVP의 두 번째 특징은 감독 컨트롤러(Supervising Controller)입니다.이 경우 뷰에는 Customer라는 속성이 있을 수 있으며 이는 다시 UI 위젯에 데이터 바인딩됩니다.뷰를 동기화하고 세부적으로 관리하는 것에 대해 생각할 필요가 없으며 감독 컨트롤러는 예를 들어 복잡한 상호 작용 논리를 사용하여 필요할 때 개입하여 도움을 줄 수 있습니다.
MVP의 세 번째 "특징"(또는 누군가는 이를 별도의 패턴이라고 부를 수도 있음)은 프레젠테이션 모델(또는 때로는 Model-View-ViewModel이라고도 함)입니다.MVP와 비교하면 M과 P를 하나의 클래스로 "병합"합니다.UI 위젯에 데이터가 바인딩된 고객 개체가 있지만 "IsButtonEnabled" 또는 "IsReadOnly" 등과 같은 추가 UI 관련 필드도 있습니다.
내 생각에 UI 아키텍처에 관해 내가 찾은 최고의 리소스는 Jeremy Miller가 작성한 일련의 블로그 게시물이라고 생각합니다. 나만의 CAB 시리즈 만들기 목차.그는 MVP의 모든 특징을 다루고 이를 구현하는 C# 코드를 보여주었습니다.
또한 저는 Silverlight의 맥락에서 Model-View-ViewModel 패턴에 대해 블로그에 게시했습니다. YouCard 재방문:ViewModel 패턴 구현.
모델-뷰-컨트롤러
MVC 소프트웨어 애플리케이션의 아키텍처 패턴입니다.이는 애플리케이션 로직을 세 가지 개별 부분으로 분리하여 모듈성을 촉진하고 협업 및 재사용을 용이하게 합니다.또한 애플리케이션을 더욱 유연하게 만들고 반복을 환영하게 만듭니다. 애플리케이션을 다음 구성 요소로 구분합니다.
- 모델 데이터 및 비즈니스 로직 처리
- 컨트롤러 사용자 인터페이스와 애플리케이션을 처리하기 위해
- 견해 그래픽 사용자 인터페이스 객체 및 프리젠테이션 처리
이를 좀 더 명확하게 하기 위해 간단한 쇼핑 목록 앱을 상상해 보겠습니다.우리가 원하는 것은 이번 주에 구매해야 하는 각 품목의 이름, 수량 및 가격 목록뿐입니다.아래에서는 MVC를 사용하여 이 기능 중 일부를 구현하는 방법을 설명합니다.
모델-뷰-발표자
- 그만큼 모델 뷰(사용자 인터페이스)에 표시될 데이터입니다.
- 그만큼 보다 데이터(모델)를 표시하고 해당 데이터에 따라 작동하도록 사용자 명령(이벤트)을 Presenter로 라우팅하는 인터페이스입니다.뷰에는 일반적으로 Presenter에 대한 참조가 있습니다.
- 그만큼 증여자 "중간자"(MVC의 컨트롤러가 담당)이며 뷰와 모델 모두에 대한 참조를 가지고 있습니다. '모델'이라는 단어에 주목하세요. 오해의 소지가 있습니다.오히려 그래야 한다 모델을 검색하거나 조작하는 비즈니스 로직.예를 들어:데이터베이스 테이블에 User를 저장하는 데이터베이스가 있고 View가 사용자 목록을 표시하려는 경우 Presenter는 Presenter가 사용자 목록을 쿼리할 데이터베이스 비즈니스 로직(DAO 등)에 대한 참조를 갖게 됩니다.
간단한 구현 샘플을 보고 싶으시다면 확인해주세요 이것 깃허브 포스트
데이터베이스에서 사용자 목록을 쿼리하고 표시하는 구체적인 작업 흐름은 다음과 같이 작동할 수 있습니다.
이것은 차이점 ~ 사이 MVC 그리고 MVP 패턴?
MVC 패턴
컨트롤러는 동작을 기반으로 하며 뷰 간에 공유될 수 있습니다.
표시할 뷰를 결정하는 역할을 담당할 수 있음(전면 컨트롤러 패턴)
MVP 패턴
뷰는 모델과 더 느슨하게 결합됩니다.프리젠터는 모델을 뷰에 바인딩하는 일을 담당합니다.
뷰와의 상호작용이 인터페이스를 통해 이루어지기 때문에 단위 테스트가 더 쉽습니다.
일반적으로 발표자 지도를 일대일로 봅니다.복잡한 뷰에는 발표자가 여러 명 있을 수 있습니다.
이 두 프레임워크는 모두 데이터 소스(모델), 애플리케이션 로직(또는 이 데이터를 유용한 정보로 전환)(컨트롤러/프레젠터) 및 디스플레이 코드(뷰)와의 상호 작용과 같은 별도의 문제를 목표로 합니다.어떤 경우에는 모델을 사용하여 데이터 소스를 더 높은 수준의 추상화로 전환할 수도 있습니다.이에 대한 좋은 예는 다음과 같습니다. MVC 스토어프론트 프로젝트.
토론이 있습니다 여기 MVC와 MVP의 차이점에 대해.
차이점은 MVC 애플리케이션에서는 전통적으로 뷰와 컨트롤러가 모델과 상호 작용하지만 서로 상호 작용하지는 않는다는 것입니다.
MVP 디자인에서는 발표자가 모델에 액세스하고 뷰와 상호 작용하도록 합니다.
그렇긴 하지만, ASP.NET MVC는 이러한 정의에 따라 MVP 프레임워크입니다. 컨트롤러가 모델에 액세스하여 논리가 없는 뷰를 채우기 때문입니다(컨트롤러가 제공하는 변수만 표시함).
ASP.NET MVC와 MVP의 차이점에 대한 아이디어를 얻으려면 다음을 확인하세요. 이번 MIX 프레젠테이션 스콧 핸셀먼 지음.
둘 다 프레젠테이션과 비즈니스 로직을 분리하려는 패턴으로, UI 측면에서 비즈니스 로직을 분리합니다.
구조적으로 MVP는 MVC가 Front Controller 기반 접근 방식인 페이지 컨트롤러 기반 접근 방식입니다.즉, MVP 표준 웹 양식에서는 페이지 수명 주기가 코드 숨김에서 비즈니스 논리를 추출하여 향상된다는 의미입니다.즉, 페이지는 http 요청을 서비스하는 페이지입니다.즉, MVP IMHO는 웹 형식의 진화적인 향상 유형입니다.반면에 MVC는 페이지가로드되기 전에 컨트롤러 클래스에 의해 요청이 가로 채기 때문에 게임을 완전히 변경하고, 비즈니스 로직이 실행 된 다음 컨트롤러 처리의 최종 결과에서 데이터가 페이지 ( "보기")에 덤프 된 최종 결과에서 그 결과로 게임을 완전히 변경합니다. Sense, MVC는 (적어도 나에게) 라우팅 엔진으로 향상된 MVP의 컨트롤러 맛을 감독하는 데 많은 것을 보게됩니다.
둘 다 TDD를 가능하게 하며 단점과 장점이 있습니다.
IMHO 중 하나를 선택하는 방법에 대한 결정은 ASP NET 웹 양식 유형의 웹 개발에 투자한 시간을 기반으로 해야 합니다.자신이 웹 양식에 능숙하다고 생각한다면 MVP를 제안하고 싶습니다.페이지 수명 주기 등의 측면에서 불편함을 느끼는 경우 MVC를 사용하는 것이 좋습니다.
이 주제에 대해 좀 더 자세히 설명하는 또 다른 블로그 게시물 링크가 있습니다.
저는 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에서 값을 변경할 때 이를 설정합니다.
따라서 예를 들어 모델이 자동차라면 발표자는 일종의 자동차 발표자이며 자동차 속성(연도, 제조업체, 좌석 등)을 뷰에 노출합니다.뷰는 'carmaker'라는 텍스트 필드가 Presenter Maker 속성을 표시해야 한다는 것을 알고 있습니다.
그런 다음 다양한 유형의 발표자 뷰에 바인딩할 수 있으며 모두 Maker 속성을 가지고 있어야 합니다. 비행기, 기차 등 무엇이든 가능하며 뷰는 상관하지 않습니다.뷰는 합의된 인터페이스를 구현하는 한 프리젠터로부터 데이터를 가져옵니다.
이 바인딩 프레임워크를 제거하면 실제로는 컨트롤러입니다. :-)
따라서 MVP는 MVC의 진화라고 볼 수 있습니다.
MVC는 훌륭하지만 문제는 일반적으로 뷰당 컨트롤러가 있다는 것입니다.컨트롤러 A는 뷰 A의 필드를 설정하는 방법을 알고 있습니다.이제 뷰 A가 모델 B의 데이터를 표시하도록 하려면 컨트롤러 A가 모델 B를 알아야 하거나 인터페이스가 있는 객체를 수신하려면 컨트롤러 A가 필요합니다. 이는 바인딩이 없는 MVP와 같거나 다시 작성해야 합니다. 컨트롤러 B의 UI 설정 코드
결론 - MVP와 MVC는 모두 UI 패턴의 분리이지만 MVP는 일반적으로 MVC 기반의 바인딩 프레임워크를 사용합니다.따라서 MVP는 MVC보다 높은 아키텍처 수준에 있고 MVC보다 높은 래퍼 패턴입니다.
나의 겸손한 짧은 견해:MVP는 대규모용이고 MVC는 소규모용입니다.MVC를 사용하면 V와 C가 M에 직접 바인딩되기보다는 분할할 수 없는 단일 구성 요소의 양면으로 보일 수 있으며, UI 컨트롤 및 기본 위젯과 같이 더 짧은 규모로 내려갈 때 필연적으로 이에 해당합니다.이 세분성 수준에서는 MVP가 거의 의미가 없습니다.반대로 규모가 커지면 적절한 인터페이스가 더 중요해지고, 명확한 책임 할당도 마찬가지로 MVP가 됩니다.
반면에, 이러한 경험적 확장 규칙은 플랫폼 특성이 MVP보다 MVC를 구현하는 것이 더 쉬워 보이는 웹과 같이 구성 요소 간의 관계를 선호하는 경우 거의 중요하지 않을 수 있습니다.
있다 이것 Bob 삼촌이 마지막에 MVC와 MVP에 대해 간략하게 설명하는 멋진 비디오입니다.
IMO, MVP는 기본적으로 표시할 내용(데이터)과 표시 방법(뷰)에 대한 관심을 분리하는 향상된 MVC 버전입니다.Presenter에는 UI의 비즈니스 로직이 포함되어 있으며 어떤 데이터가 표시되어야 하는지 암시적으로 지정하고 멍청한 뷰 모델 목록을 제공합니다.그리고 데이터를 표시할 때가 오면 뷰(아마도 동일한 ID 포함)를 어댑터에 연결하고 최소한의 코드가 도입되는 뷰 모델을 사용하여 관련 뷰 필드를 설정하기만 하면 됩니다(단지 setter 사용).주요 이점은 가로 목록이나 세로 목록에 항목을 표시하는 것과 같은 다양한 보기에 대해 UI 비즈니스 논리를 테스트할 수 있다는 것입니다.
MVC에서는 인터페이스(경계)를 통해 서로 다른 레이어를 연결합니다.컨트롤러는 우리 아키텍처의 플러그인이지만 표시할 항목을 부과하는 데 제한이 없습니다.그런 의미에서 MVP는 어댑터를 통해 컨트롤러에 연결 가능한 뷰 개념을 갖춘 일종의 MVC입니다.
이것이 더 나은 도움이 되기를 바랍니다.
MVC에는 여러 버전이 있습니다. 이 답변은 Smalltalk의 원래 MVC에 관한 것입니다.간단히 말해서, 그것은
이 이야기 droidcon NYC 2017 - 아키텍처 구성요소를 사용한 깔끔한 앱 디자인 그것을 명확히 한다
가장 간단한 대답은 뷰가 모델과 상호 작용하는 방식입니다.MVP에서 뷰는 뷰와 모델 사이의 중개자 역할을 하는 프리젠터에 바인딩되어 뷰에서 입력을 받고 모델에서 데이터를 가져온 다음 비즈니스 로직을 수행하고 마지막으로 뷰를 업데이트합니다.MVC에서 모델은 컨트롤러를 거치지 않고 뷰를 직접 업데이트합니다.
제 생각엔 Erwin Vandervalk가 만든 이 이미지(그리고 그에 수반되는 이미지)는 다음과 같습니다. 기사)는 MVC, MVP 및 MVVM과 유사점 및 차이점을 가장 잘 설명합니다.그만큼 기사 기사 제목에 "MVC" 및 "MVP"라는 단어가 포함되어 있지 않기 때문에 "MVC, MVP 및 MVVM"에 대한 쿼리에 대한 검색 엔진 결과에 표시되지 않습니다.하지만 내 생각엔 그게 최선의 설명인 것 같아.
(그만큼 기사 또한 밥 마틴(Bob Martin) 삼촌이 그의 연설 중 하나에서 말한 것과도 일치합니다:MVC는 원래 시스템 아키텍처가 아닌 작은 UI 구성 요소를 위해 설계되었습니다)
MVP
MVP는 모델-뷰-프레젠터를 나타냅니다.이는 Microsoft가 Smart Client Windows 응용 프로그램을 도입한 2007년 초에 나타났습니다.
Presenter는 모델의 View 이벤트와 비즈니스 로직을 바인딩하는 MVP에서 감독 역할을 합니다.
보기 이벤트 바인딩은 보기 인터페이스의 Presenter에서 구현됩니다.
View는 사용자 입력의 시작자이며 이벤트를 Presenter에 위임하고 Presenter는 이벤트 바인딩을 처리하고 모델에서 데이터를 가져옵니다.
장점:View는 UI만으로도 논리가 아닙니다. 높은 수준의 테스트 가능성
단점:이벤트 바인딩 구현 시 약간 복잡하고 작업이 더 많음
MVC
MVC는 모델-뷰-컨트롤러를 나타냅니다.컨트롤러는 바인딩 모델을 사용하여 모델을 생성하고 뷰를 렌더링하는 역할을 담당합니다.
컨트롤러는 개시자이며 렌더링할 뷰를 결정합니다.
장점:단일 책임 원칙에 대한 강조 높은 수준의 테스트 가능성
단점:동일한 컨트롤러에서 여러 뷰를 렌더링하려고 하면 컨트롤러에 작업 부하가 너무 많이 걸리는 경우가 있습니다.
