MVC или MVP? Какой шаблон дизайна имеет больше смысла?

Question

Что вы, ребята, предпочитаете? Я изучал оба варианта, и определенно, похоже, есть некоторая непоследовательность в том, что люди называют их.

Я постараюсь записать, в чем различия, и вы можете исправить меня, если я ошибаюсь.

MVC

1. Модель содержит ссылки на своих наблюдателей (Представления), об обновлениях модели, которые она уведомляет наблюдателей.
2. Представления передают все события и сообщения контроллеру. Представления обновляют свое содержимое, когда модель получает уведомление о том, что произошло изменение. Представление содержит ссылку на контроллер и модель.
3. Контроллер содержит модель и (иногда) виды. Представления будут вызывать методы контроллеров, соответствующие пользовательскому вводу, затем контроллер соответствующим образом манипулирует моделью и иногда манипулирует видом (блокируя кнопки при определенных щелчках просмотра и т. Д.)

MVP

1. Модель не имеет ссылок на вид. Предоставляет только абстракцию данных для программы. Модель ни на что не ссылается.
2. Как и в MVC Views, вызывать соответствующие методы Presenter в зависимости от пользовательского ввода. Просмотр имеет ссылку только на докладчика.
3. Ведущий имеет ссылку на виды и модель. Когда View вызывает метод в Presenter, Presenter манипулирует моделью, а затем манипулирует представлением.

Я почти уверен, что понимаю, как работает MVC, просто я понимаю, что MVP довольно сомнительный. Мне действительно очень нравится MVC, но единственная часть, которая меня не устраивает, - это тот факт, что Модель, которая должна быть только абстракцией уровня данных, также содержит ссылки на представления и выполняет обновление. Это не имеет смысла.

Answer 1

Мартин Фаулер предлагает анализ MVC и MVP, а статья Википедии MVP дает больше ссылок.

Для меня есть два вопроса:

1). Насколько «живы» отношения Модель-Вид? Если Модель изменяется динамически, и Представления должны обновляться, чтобы отразить это изменение Модели, тогда у нас есть классический MVC, и Модель каким-то образом уведомляет соответствующие Представления об изменениях. Этот стиль не применяется к классическим веб-приложениям (например, как реализовано в Struts). Здесь обычно есть представление, созданное как единое целое с моментальным снимком модели (действительно часто в DTO, предоставляемых моделью). В большой литературе веб-стиль все еще упоминается как MVC.

2). Когда пользователь делает «что-то», кто отвечает за неинтерпретацию и действия. В MVC это обычно работа контроллеров. MVP, по-видимому, позволяет более прямое взаимодействие с View для Model для этой цели (если я правильно понимаю статью Фаулера).

Я очень предпочитаю чистое разделение интересов - подход MVC - это то, как я думаю, но это может быть просто знакомство.

Что должен выбрать человек? Как правило, я думаю, что вы руководствуетесь фреймворком, который вы решили использовать. Я родом из Struts, поэтому MVC в веб-стиле для меня естественен. Если я правильно понимаю, MVP имеет явное принятие в некоторых аспектах .NET. Я бы пошел с потоком любой фреймворк, который вы выберете, и я бы не стал отказываться от фреймворка только потому, что это MVP, а не MVC - даже если предположить, что можно провести четкое различие.

Answer 2

В любом шаблоне Модель не может зависеть от каких-либо других компонентов. «Имеет ссылки» только на объекты Observer. Не имеет значения, являются ли эти наблюдатели представлениями, контроллерами или другими моделями.

MVC является наиболее недооцененным шаблоном дизайна и не имеет реального определения. Я собираюсь использовать тот, который опубликовал Мартин Фаулер.

Давайте рассмотрим пользовательский интерфейс / экран CRUD / для сложного бизнес-объекта в настольном приложении. (Struts вроде MVC немного отличается). У вас есть одна Модель (бизнес-объект), несколько представлений на экране, каждое из которых имеет свой собственный контроллер.

Логика пользовательского интерфейса (проверка, включение виджетов, относящихся к бизнес-объекту) разбросана по объектам View и Controller. В этом смысле паттерн MVC устарел (!), Хотя в то время разделение интересов было революционным и позволило использовать более богатые интерфейсы.

В MVP у вас есть модель View, которая тупа, вся логика пользовательского интерфейса находится внутри Presenter. Presenters предоставляет элементам View действия / обработчики событий / делегаты. Таким образом, представление перезванивает докладчику только тогда, когда пользователь взаимодействует с соответствующим виджетом на экране. Presenter действует как посредник, инкапсулирует взаимодействие виджетов.

Я действительно рекомендую эту ссылку http://martinfowler.com/eaaDev/uiArchs.html. Вся тема MVC не так проста, как может показаться. Это почти теория сама по себе.

Answer 3

А как насчет MVVM? (Модель Представление View-Model) В этом стиле модель не содержит ссылок на представление и наоборот. Я не буду притворяться, что знаю много, потому что я только начинаю изучать его, но мы недавно сделали выбор, чтобы перейти к этому шаблону проектирования, поэтому я предполагаю, что он имеет некоторые достоинства.

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

Answer 4

Я думаю, что это зависит от среды, в которой вы находитесь. В веб-среде контроллер выбирает, какое представление отображать в результате запроса. Прежде чем это произойдет, контроллер проверяет, есть ли какие-либо изменения в модели. Другими словами, представление не нуждается в прямой связи с моделью.

Answer 5

Предполагая, что мое понимание верно, Модель не должна содержать ссылку на View в MVP или MVC.

Я скажу это, хотя, ваше определение того, как именно MVC / MVP должен быть реализован, может немного отличаться от следующих парней. Я думаю, что шаблон существует для общей идеи разделения интересов, но его можно адаптировать, чтобы он точно соответствовал тому, что вам нужно для конкретной реализации.