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

Question

Какая диаграмма 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

Answer 1

Они все такие.

MVC - расплывчатый шаблон.

Мой взгляд на MVC таков:

Контроллер

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

View

Имеет определение модели, прикрепленной к нему, и представляет собой просто набор функций для отображения конкретной модели.

Модель

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

//Controller
import Views

class Controller
  private Models

//View
import Model

class View

//Model
class Model

Модель не должна ничего знать о представлении / контроллере. Представление должно знать определение модели. Контроллеру необходимо иметь моделей и знать определения представлений.

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

Answer 2

MVC, строго говоря, является устаревшей моделью. Грубо говоря, он вводит зависимости между View и Model, так как Model непосредственно обновляет статус View (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),), и мы можем найти, со своей стороны, определение «нового» шаблона под названием Presentation Model (см. http://martinfowler.com/eaaDev/PresentationModel.html), или PM. Microsoft для своих технологий WPF и Silverlight определила другой шаблон, называемый Model-View-View-Presenter, или MVVM (см. http://msdn.microsoft.com/en-us/magazine/dd419663.aspx),, который имеет Presenta Модель как его вдохновение. Я думаю, что вы можете взглянуть на всех этих парней и понять, насколько они похожи (и разные). По моему скромному мнению, основная идея заключается в том, что данные и поведение Presentation остаются в Presenter, а Model не знает View (поэтому диаграмма 4 выключена, даже будучи MVC), и вы должны иметь возможность изменять View (или поддерживать другой View). реализации) безболезненно, отделены от Presenter и Model. Модель представления может обеспечить это и является эффективной и тщательной для реализации с использованием современных технологий.

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

Диаграмма 1 является правильным изображением шаблона MVC.

Сплошные линии представляют реальную ссылку, как в переменной. Это означает, что вы должны ожидать увидеть экземпляр модели как в представлении, так и в контроллере.

Пунктирные линии представляют вызовы функций или сообщения от одного к другому. Пунктирная линия от модели к представлению реализуется через шаблон Observer, где что-то изменилось в модели и имеет ссылку на представление (через API наблюдателя модели), где он вызывает метод. Нечто подобное observer[i].update("name", value, self), которое вызывается в модели при каждом изменении.

Пунктирная линия между представлением и контроллером - это представление, отправляющее сообщение контроллеру. Представьте себе кнопку в пользовательском интерфейсе, которая нажата. Контроллер прослушивает это событие и обрабатывает его.

Примером коммуникационного потока может быть нажатие кнопки: Просмотр отправляет сообщение контроллеру. Контроллер обрабатывает это событие, где он обновляет свой экземпляр модели, скажем model.name. Модель имеет метод setter, который обновляет name и вызывает метод наподобие changed, который затем зацикливается на своих наблюдателях и вызывает .update для каждого наблюдателя. Представление, ранее subscribed для Модели и получающее update, вызывается со старым и новым значениями name. Метод update в представлении обновляет значение имени в label. Готово.

Слайд-колода, описывающая MVC: https://pl.csie.ntut.edu.tw/~ctchen/pdf/InsideSmalltalkMVC-public.pdf

C2 Wiki MVC статья: http://wiki.c2.com/?ModelViewController

Answer 6

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

Answer 7

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

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

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