В чем разница между этими двумя диаграммами MVC?
Существует множество разновидностей архитектуры MVC, и на диаграммах представлены две такие разновидности. Я назову два основных варианта «GUI-MVC» и «Web-MVC».
GUI-MVC, как он возник в сообществе Smalltalk
MVC возник в контексте приложений с графическим интерфейсом Smalltalk 80-х годов. Основополагающим документом по этому шаблону является «Поваренная книга по использованию парадигмы пользовательского интерфейса модель-представление-контроллер в Smalltalk-80» Краснера и Поупа (1988). На момент написания PDF-файл доступен здесь. Они показывают следующую диаграмму для архитектуры MVC:
Говоря современным языком, модель содержит бизнес-логику, но также представляет текущее состояние, представление отображает состояние модели посредством привязки данных, а контроллер содержит обработчики событий для пользовательского ввода.
Ваша первая диаграмма суммирует основной поток данных в этой традиционной архитектуре GUI-MVC. В целом она похожа на диаграмму Краснера и Поупа, но представляет пользователя как явную часть системы и исключает дополнительные пути связи (такие как уведомления Модель→Контроллер, Контроллер→Обновления представления и Доступ к Представлению→Модели).
Web-MVC, перенос этих терминов в контекст Web/HTTP
В веб-контексте термин «MVC» используется для описания существенно отличающейся архитектуры. Раньше, когда Web-MVC был популярен, не было связи в реальном времени между интерфейсами и серверами (как сейчас с WebSockets). Были только HTTP-запросы.
Таким образом, лучшие практики GUI-MVC были переработаны в термины взаимодействия между сервером и клиентом. Модель содержит бизнес-логику и постоянные данные. Представление — это HTML (или другое представление), которое отображается для пользователей. Контроллер — это компонент, который обрабатывает HTTP-запросы на серверной части и преобразовывает их в операции модели, такие как обновление баз данных. Иногда утверждается, что приложения следуют архитектуре MVC, если веб-сервер использует механизм шаблонов (для представлений) и ORM (для модели), интерпретация, которая сильно отличается от GUI-MVC.
Ваша вторая диаграмма суммирует потоки данных в этой разновидности архитектуры Web-MVC.
Различные интерпретации слова «Контроллер».
Существует принципиальное различие, особенно в роли контроллера между этими архитектурами.
В GUI-MVC представление использует контроллер для обработки событий. Например, представление может вызывать методы контроллера для обработки щелчка мыши или сочетания клавиш. Затем контроллер вызывает подходящие методы в модели. Через databinding/observers/pubsub представление уведомляется об обновлениях в модели и показывает новое состояние.
В Web-MVC контроллер опосредует все взаимодействие с моделью. Подобно GUI-MVC, контроллер вызывает операции модели. Но затем в инверсии потока данных GUI-MVC контроллер Web-MVC загружает соответствующие данные из модели, создает новое представление (например, путем рендеринга HTML-шаблона) и возвращает его клиенту. Прямая связь между моделью и представлением отсутствует, и на практике контроллер начинает брать на себя ответственность и от представления, и от модели (особенно в приложениях CRUD).
Связанные архитектуры
Впоследствии было разработано еще много архитектур, например:
- Model-View-Presenter (MVP) представляет презентатора, роль, аналогичную контроллеру Web-MVC, который также отвечает за управление представлениями.
- Model-View-ViewModel (MVVM) представляет модель представления, цель привязки данных, которая похожа на модель в GUI-MVC, но не содержит бизнес-логики.
Как выбрать подходящую архитектуру
Ничто из этого сейчас не особенно полезно при создании новых архитектур. Вполне вероятно, что вы используете какую-то структуру графического интерфейса. Эта структура графического интерфейса, вероятно, наложит определенную архитектуру или поток данных. Например, при разработке веб-интерфейса такие фреймворки, как React или Vue, предлагают привязку данных, что сильно подталкивает вас к представлениям, подобным GUI-MVC, но не обязательно обеспечивает разделение контроллера и модели. Я рекомендую следовать руководствам по разработке приложений, предлагаемым в документации по вашей платформе.
Обе эти диаграммы слишком расплывчаты, чтобы рассуждать о них в деталях.
Например, давайте попробуем составить утверждения из представленных на диаграмме соединений между компонентами, для первой диаграммы мы могли бы сказать:
Пользователь «Использует» Контроллер; Контроллер «манипулирует» моделью; Модель «обновляет» представление; Представление «видит» пользователя.
Последнее не имеет большого смысла, почему представления видят пользователя? (Потому что они хотят, чтобы диаграмма превратилась в полный круг. Вероятно, слово «Подарки» было бы более подходящим для метки со стрелкой.)
На второй диаграмме, согласно отмеченным стрелкам, Контроллер запрашивает данные Модели, но не имеет возможности запросить изменения Модели — это явное упущение.
Я указываю на них, чтобы показать, что они абстрактны, и неясно, на чем они сосредоточены, а что намеренно опущено, поэтому их трудно воспринимать всерьез, особенно при прямом сравнении друг с другом. Кроме того, один касается какого-то высокоуровневого взаимодействия между компонентами (манипуляции, обновления, которые не разбиты на направленный обмен сообщениями), а другой — обмена сообщениями типа запроса и ответа между компонентами, которые выполняют (неуказанные) взаимодействия более высокого уровня.
Тем не менее, следуя диаграммам, последний отводит контроллеру более центральную роль в том, что он взаимодействует со всеми остальными компонентами, что кажется мне более реалистичным.
Системы MVC должны допускать несколько представлений; обычно контроллер запрашивает создание новых представлений, но на этой первой диаграмме связь между контроллером и представлением, по-видимому, проходит через модель. Это может иметь смысл в некоторых контекстах, если некоторые представления на самом деле являются формальной частью модели, но некоторые представления или их варианты являются частными для пользователя или его сеанса, что требует дополнительной связи с моделью.
Рекомендую посмотреть эти видео для лучшего погружения в вопрос: