MVC 또는 MVP? 어떤 디자인 패턴이 가장 합리적입니까?

Question

어느 쪽이 더 좋습니까? 나는 둘 다 조사해 보았고 사람들이 부르는 것에 일관성이없는 것 같다.

나는 차이점이 무엇인지 적어두고 내가 틀렸다면 나를 바로 잡을 수 있습니다.

MVC

1. 모델은 관찰자에게 통지 모델에 대한 업데이트에 그것의 자신의 관찰자 (조회수)에 대한 참조를 보유하고있다.
2. 뷰는 모든 이벤트와 메시지를 컨트롤러로 전달합니다. 뷰는 변경 내용이 모델에 의해 통지 될 때 해당 내용을 업데이트합니다. 뷰에는 컨트롤러 및 모델에 대한 참조가 있습니다.
3. 컨트롤러는 모델과 (때로는) 뷰를 보유합니다. 사용자 입력에 대응하는 컨트롤러 메소드를 호출보기는, 제어기는 다음과 같은 따라서 모델 maniuplates, 때로는 (소정의 클릭 수의 버튼을 차단 등) 뷰

MVP를 조작

1. 모델에 뷰에 대한 참조가 없습니다. 프로그램에 대한 데이터 추상화 만 제공합니다. 모델은 아무 것도 언급하지 않습니다.
2. MVC보기에서와 마찬가지로 사용자 입력에 따라 해당 Presenter 메서드를 호출합니다. 보기에는 발표자에 대한 참조 만 있습니다.
3. Presenter에는보기 및 모델에 대한 참조가 있습니다. View가 Presenter에서 메서드를 호출하면 Presenter는 Model을 조작 한 다음 View를 조작합니다.

저는 MVP가 작동하는 방식을 잘 알고 있습니다. MVP가 iffy 일 경우 내 이해입니다. 정말 MVC가 정말 좋아요.하지만 저와 잘 어울리지 않는 유일한 부분은 데이터 계층의 추상화 인 Model이 뷰에 대한 참조를 보유하고 업데이트한다는 사실입니다. 그건 말이되지 않습니다.

Answer 1

마틴 파울러는 MVC와 MVP의 analysis 제공하며, 위키 백과 MVP 문서의 참조를 제공합니다.

저에게는 두 가지 질문이 있습니다.

1). 모델 - 뷰 관계는 "라이브"상태입니까? 모델이 동적으로 변경되고 뷰가 모델 변경을 반영하도록 업데이트해야한다면 우리는 고전적인 MVC를 가지고 있고 모델은 어떻게 든 관련 뷰를 알립니다. 이 스타일은 고전적인 웹 애플리케이션에는 적용되지 않습니다 (예 : Struts에서 구현 됨). 일반적으로 모델의 스냅 샷 중 하나 (실제로는 모델에서 제공하는 DTO)에서 생성 된 뷰가 있습니다. 많은 문학에서 웹 스타일은 여전히 ​​MVC라고합니다.

2). 사용자가 "무언가"를 할 때, 누가 비판과 행동을 책임지고 있습니다. MVC에서는 일반적으로 Controller 작업입니다. MVP는이 목적을 위해 View에서 Model 로의 더 직접적인 상호 작용을 허용하는 것으로 보입니다 (Fowlers 기사를 올바르게 이해 한 경우).

나는 MVC 접근 방식이 내가 생각하는 방법이지만, 그것은 친숙한 것일 수있다.

사람이 무엇을 선택해야합니까? 일반적으로, 나는 당신이 사용하기로 선택한 프레임 워크에 이끌린다고 생각합니다. Struts 배경에서 왔기 때문에 웹 스타일 MVC는 자연 스럽습니다. 내가 올바르게 이해하면 MVP는 .NET의 일부 측면에서 명시 적으로 채택됩니다. MVC보다는 MVP이기 때문에 프레임 워크를 거부하지 않을 것입니다. 심지어 명확한 구분이 가능할 수도 있다고 가정합니다.

Answer 2

내 이해가 맞다고 가정하면 MVP 또는 MVC의 뷰에 대한 참조가 모델에 보유되어서는 안됩니다.

MVC/MVP 구현 방법에 대한 정의가 다음 사람과 약간 다를 수 있습니다. 나는이 패턴이 우려의 분리라는 일반적인 생각에 맞다고 생각하지만, 특정 구현에 필요한 것과 정확히 일치하도록 적용될 수 있습니다.

Answer 3

환경에 따라 다르다고 생각합니다. 웹 환경에서 컨트롤러는 요청한 결과로 어떤보기를 표시할지 선택합니다. 그런 일이 일어나기 전에 컨트롤러는 모델에 변경 사항이 있는지 확인합니다. 즉, 뷰는 모델과 직접 연결될 필요가 없습니다.

Answer 4

MVVM은 어떻습니까? (Model View View-Model)이 스타일에서는 모델이 뷰에 대한 참조를 보유하지 않으며 그 반대의 경우도 마찬가지입니다. 나는 단지 그것을 배우기 시작했기 때문에 많이 알지는 않겠지 만, 최근에이 디자인 패턴으로 옮길 선택을했습니다. 그래서 나는 그것이 장점이 있다고 가정합니다.

http://en.wikipedia.org/wiki/Model_View_ViewModel

Answer 5

어느 패턴에서나 모델은 다른 구성 요소에 의존 할 수 없습니다. Observer 객체에만 '참조 있음'이 있습니다. 이러한 관측자가 뷰, 컨트롤러 또는 다른 모델인지는 상관하지 않습니다.

MVC는 가장 잘못 인용 된 디자인 패턴이며 실제 정의가 없습니다. 마틴 파울러 (Martin Fowler)가 출판 한 것을 사용하겠습니다.

데스크톱 응용 프로그램의 복잡한 비즈니스 개체에 대한 UI/CRUD 화면 /을 생각해 보겠습니다. MVC와 같은 Struts는 약간 다릅니다. 하나의 모델 (비즈니스 개체)과 여러 개의보기가 화면에 있으며 각보기에는 자체 컨트롤러가 있습니다.

UI 로직 (유효성 검증, 비즈니스 오브젝트와 관련된 위젯 사용 가능)이 View 및 Controller 오브젝트 전체에 분산되어 있습니다. 이러한 의미에서 MVC 패턴은 시대에 뒤 떨어지고 (!) 당시에는 관심사의 분리가 혁명적이었고보다 풍부한 UI를 사용할 수있었습니다.

MVP에는보기가 있는데,보기가 멍청합니다. 모든 UI 로직이 발표자 안에 있습니다. 발표자는 View 요소에 작업/이벤트 처리기/대리인을 제공합니다. 따라서보기는 사용자가 화면에서 해당 위젯과 상호 작용할 때만 발표자에게 다시 전화합니다. Presenter는 중재자의 역할을 수행하고 위젯이 상호 작용하는 방식을 캡슐화합니다.

이 링크를 정말 추천합니다. http://martinfowler.com/eaaDev/uiArchs.html. 전체 MVC 주제가 소리처럼 쉽지는 않습니다. 그것은 거의 하나의 이론입니다.