Подтвердить что ты не робот

Какая диаграмма MVC правильная? (Веб-приложение)

Какая диаграмма MVC верна? У каждого есть разные стрелки...

Диаграмма 1

Диаграмма 2

http://blog.stannard.net.au/blog/media/simple-mvc-framework/mvc.gif

Диаграмма 3

Диаграмма 4

http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif

Диаграмма 5

http://www.shopno-dinga.com/dustbin/mvc.png

4b9b3361

Ответ 1

Все они.

MVC - это неопределенный шаблон.

Мой взгляд на MVC заключается в следующем:

контроллер

Объект имеет набор моделей и имеет методы просмотра и редактирования моделей. Он говорит с моделями и возвращает экземпляры представлений с применяемыми ими моделями.

Просмотр

Подходит ли к нему определение модели и представляет собой набор функциональных возможностей для отображения конкретной модели.

Model

Инкапсулирует данные. Имеет методы для возврата состояния и изменения состояния.

//Controller
import Views

class Controller
  private Models

//View
import Model

class View

//Model
class Model

Модель не должна ничего знать о View/Controller. A View должен знать определение модели. Контроллер должен владеть Моделями и должен знать определения видов.

Вы можете связать их более плотно, что необязательно.

Ответ 2

MVC, строго говоря, является своего рода устаревшим шаблоном. Грубо говоря, он вводит зависимости между View и Model, так как обновляет модель. (http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/MVC.htm), как показано на диаграмме 4, где вы видите прямое взаимодействие между Model и View, в соответствии с оригиналом MVC, исторической формулировкой и это нежелательно. Фактически, сегодня мы модифицировали версии MVC, а иногда описываем MVP и называем это MVC. Аббревиатура "MVC" использовалась с такой большой свободой, что все, что у вас есть три элемента под названием Model, View и Controller, в основном MVC, несмотря на детали реализации и определения ответственности. Разница действительно тонкая между MVC и MVP, когда вы их описываете, и находится в определении обязанностей View и Presenter (Controller). Мартин Фаулер фактически передал MVP (и MVC) несколько лет назад (http://www.martinfowler.com/eaaDev/ModelViewPresenter.html), и мы можем с его стороны найти, определение "нового" шаблона "Модель представления" (см. http://martinfowler.com/eaaDev/PresentationModel.html) или PM. Microsoft определила для своих технологий WPF и Silverlight еще один шаблон под названием Model-View-View-Presenter или MVVM (см. http://msdn.microsoft.com/en-us/magazine/dd419663.aspx), который В качестве своего вдохновения есть модель представления. Я думаю, вы можете взглянуть на всех этих парней и понять, насколько они похожи (и разные). По моему скромному мнению, основная идея заключается в том, что данные презентации и поведение остаются в Presenter, Model не знает View (поэтому диаграмма 4 выключена, даже будучи MVC), и вы должны иметь возможность изменять View (или поддерживать другой вид реализаций) безболезненным способом, отделенным от обоих презентаторов и моделей. Модель презентации может обеспечить эту и эффективную и тщательную реализацию с использованием современных технологий.

Ответ 3

На самом деле есть небольшая разница.

Существует два типа моделей: активная модель и пассивная модель: первая имеет механизм уведомления, а второй - просто не знает, что используется в MVC.

Первая и четвертая диаграммы представляют MVC с активной моделью.

Подробнее об этом вы можете прочитать здесь.

Ответ 4

Диаграммы 1 и 4 являются правильными шаблонами MVC. Остальные ближе к шаблону MVP.

Хотя в веб-MVC у вас есть пассивная модель, а изменения вытягиваются из представления из модели, а не подталкиваются моделью (шаблон наблюдателя).

Ответ 5

Ни один из них не является на самом деле неправильным, но существует другой подход для MVC MVC и клиентской стороны MVC на основе Web (запрос/ответ).

В веб-среде контроллер отвечает за обращение с запросом пользователей, модификацию модели (если применимо), поиск правильного представления, назначение этой информации модели в представление и возврат ее пользователю.

В более прямой интерпретации исходного шаблона MVC (говорить на настольных приложениях) модель обновляет представление напрямую, всякий раз, когда он изменяется, и контроллер имеет дело с логикой ввода и логикой приложения, соответствующим образом обновляя модель. Это не работает для обычных веб-приложений, поскольку, поскольку HTTP не имеет статуса и без использования каких-либо других более современных технологий (например, длинного опроса Ajax или веб-сайтов, как указано в комментарии), сервер не может действительно уведомлять клиента об изменениях в модели.

Ответ 6

Диаграммы 2, 3 и 5 являются точными для MVC. Когда вы отправляете запрос контроллеру, он выполняет операцию с использованием моделей, а затем отвечает.