В данной статье рассматриваются модели проектирования MVC, MVP и PAC. Они предназначены для разработки интерактивных приложений, путем разделения каждого из них на несколько связанных между собой компонент. Данные модели похожи, однако каждая из них имеет свою область применения и необходимо правильно понимать для чего предназначена каждая из моделей.

Шаблон проектирования Model-View-Controller нацелен на разделение домена приложения, пользовательского интерфейса и взаимодействия с пользователем на три отдельные части. Он был изобретен с целью обеспечения интерфейса пользователям для управления несколькими видами данных. Следующая диаграмма показывает структуру шаблона Smalltalk-80 MVC:

• Model (Модель) - данные приложения. Представляет собой состояние, структуру и поведение данных с которыми взаимодействует пользователь. Модель не содержит прямую ссылку на Представление или Контроллер и может быть изменена Представлением или Контроллером. Когда необходимо уведомить Представление и Контроллер, о том, что данные изменились, Модель использует Observer Pattern для отправки сообщения.
• View (Представление) - визуальное представление Модели. Состоит из экранов и виджетов. Представление в основном связано с выводом данных, в то время как Контроллер имеет дело с входными сигналами (с клавиатуры, мыши и т.д.). Представление может получать доступ к данным Модели и изменять их.
• Controller (Контроллер) - реагирует на ввод пользователя с клавиатуры или мыши. Выступает в качестве связующего звена между человеком и программой. Работает вместе с Представлением. Каждое Представление связано с одним Контроллером. И Представление и Контроллер поддерживают прямую связь с Моделью. Контроллер, также как и Представление может получать доступ к данным Модели и изменять их.

Существует общее заблуждение о взаимосвязи между компонентами MVC. Многие считают, что цель Контроллера - это отделение Представления от Модели. Однако, шаблон MVC позволяет отвязать домен приложения от интерфейса путем использования специального паттерна (Observer Pattern), а не через Контроллер. Контроллер был задуман в качестве посредника между пользователем и приложением, а не между Представлением и Моделью.

С появлением Интернет появился аналог оригинального шаблона MVC для использования при разработке веб приложений (Web-based MVC). По аналогии с оригинальным MVC, Web-based MVC помогает разделить домен приложения (на стороне клиента), представление и обработку ввода (на стороне сервера) на три отдельные части.

Следующая диаграмма представляет собой описание того, как шаблон MVC адаптирован для разработки веб приложений:

• Фронт-Контроллер (Front Controller) - управляет общими проблемами инфраструктуры, а также отвечает за координацию запросов к отдельным Контроллерам. Он может принимать форму сервлета в приложениях на базе Java или IHttpHandler в приложениях на основе ASP.Net. При получении HTTP-запроса Фронт-Контроллер выполняет любое общее поведение, а затем использует информацию, полученную из запросы, чтобы определить конкретный Контроллер. После того, как контроллер определен, запрос делегируется для дальнейшей обработки. После получения запроса, соответствующие операции выполняются на Модели и затем управление передается на Представление.
• Модель (Model) - инкапсулирует данные и бизнес функциональность приложения.
• Представление (View) - является содержимым (зачастую HTML и связанный с ним скрипт), которое возвращается клиенту. В данном случае Observer Pattern не используется в процессе обновления Представления в связи с тем, Представление визуализируется заново при каждом новом запросе.
• Контроллер (Controller) - компонент, который реагирует на ввод данных пользователя. В отличие от стандартного шаблона MVC, Контроллер не принимает сигналы непосредственно от аппаратных устройств, таких как клавиатура, мышь и т.д. В данном случае Контроллеры обрабатывают делегированные HTTP-запросы (или информацию, полученную от запроса, в зависимости от конкретной реализации).

Шаблон Model-View-Presenter является вариацией шаблона Model-View-Controller и также разделяет домен приложения, представление и пользовательский ввод на отдельные компоненты. Всего существует несколько общепринятых шаблонов под названием “Model-View-Presenter”. В связи с этим, в данной статье рассматривается оригинальный шаблон Model-View-Presenter наряду с некоторым его наиболее популярными вариантами.

Данный шаблон разделяет данные приложения, данные спецификации, операции с данными, координацию приложения, взаимодействие с пользователем и представление на отдельные компоненты.

На следующей диаграмме показана структура шаблона Taligent Model-View-Presenter:

• Модель (Model) - данные и бизнес-функциональность приложения.
• Селекторы (Selectors) - компоненты, которые указывают, над какой частью данных Модели производится работа.
• Команды (Commands) - компоненты, которые определяют операции для работы с данными.
• Представление (View) - визуальное представление Модели (состоит из экранов и виджетов).
• Посредники (Interactors) - компоненты, которые определяют как пользовательские события сопоставляются с операциями, выполняющимися над Моделью. Несут ответственность за перехват пользовательских событий. Являются аналогами Контроллеров MVC.
• Презентер (Presenter) - компонент, который организовывает общее взаимодействие других компонент внутри приложения. Поддерживает жизненный цикл, взаимоотношения между компонентами. Для каждого виджета не нужен свой Презентер.

Данный шаблон разделяет домен приложения, представление и логику представления на отдельные части: Model, View, Presenter.

На следующей диаграмме показана структура шаблона Dolphin Smalltalk Model-View-Presenter.

• Модель (Model) - относится к данным и бизнес-функциональности приложения.
• Представление (View) - визуальное представление (состоит из экранов и виджетов). Перехватывает начальные пользовательские события, генерируемые операционной системой. В некоторых случаях Представление отвечает на пользовательские события путем обновления данных Модели напрямую. Но в большинстве случаев пользовательские события передаются Презентеру.
• Презентер (Presenter) - компонент, который содержит логику представления, взаимодействующую с Моделью. Обычно существует один презентер, который обрабатывает обновление данных Модели для конкретного Представления.

Кажется, что различий данными шаблонами нет. Оба состоят из трех частей. Оба паттерна имеют Модель и Представление. Контроллер MVC и Презентер Dolphin SmallTalk MVP участвуют в обновлении Модели. Однако, их главное отличие состоит в понимании основных функций Контроллера и Презентера. Сравним их функции.

Контроллер в MVC:

• перехват ввода данных пользователя (основная цель)
• обновление Модели (побочная цель)

Презентер в MVP:

• обновление Модели (основная цель)
• перехват событий, делегированные Представлением (побочная цель)

Данный шаблон разделяет представление и логику представления приложения на отдельные компоненты: View и Controller. На Представление (View) возложена ответственность простой логики визуализации, а Контроллер (Controller) предназначен для реагирования на пользовательский ввод и обработку сложной логики представления.

На следующей диаграмме показана структура шаблона Supervising Controller:

Данный шаблон разделяет представление и логику представления приложения на отдельные компоненты: Представление (View) и Контроллер (Controller). Контроллер берет на себя ответственность за реагирование на события пользователя и логику представления. В отличие от Supervising Controller Pattern, в данном паттерне Представление не поддерживает никакой связи с доменным слоем и полагается исключительно на Контроллер.

На следующей диаграмме показана структура шаблона Passive View

Шаблон PAC представляет собой архитектуру, которая разделяет приложение по иерархии взаимодействующих компонентов. Каждый уровень состоит из Презентации (Presentation), Абстракции (Abstraction) и Контроля (Control). PAC стремится разложить приложение на иерархию абстракций для достижения согласованного фреймворка на любом уровне абстракции в приложении.

На следующей диаграмме показана диаграмма шаблона PAC:

• Презентация (Presentation) - является визуальным представлением. Отвечает за определение того, как пользователь взаимодействует с системой.
• Абстракция (Abstraction) - является бизнес-функциональностью домена внутри приложения.
• Контроль (Control) - компонент, которые поддерживает согласованность между абстракциями в системе и их представлении пользователю. Общается с другими Контролями в рамках одной системы.

В следующей таблице представлено краткое сравнение компонентов вышеуказанных моделей с их описанием и ролями в архитектуре.

Были рассмотрены шаблоны проектирования Model-View-Controller, Model-View-Presenter, and Presentation-Abstraction-Control. Все они похожи во многих отношениях, однако каждый из них предназначен для решения своей конкретной задачи.