MVP and MVC Part 2

Эта статья содержит вступление, общее представление и сравнение трех архитектурных шаблонов построения интерактивных приложений: Model-View-Controller, Model-View-Presenter и Presentation-Abstraction-Control.

Часть 1, Часть 2, TBD.

Вариации и производные шаблонов

Классический шаблон Model-View-Controller сейчас по большей части не используется в первоначальном дизайне, хотя из него выросло несколько вариаций, адаптированных к новым платформам разработки таким, как Microsoft Windows и Web. О двух из этих вариаций, Model-View-Presenter и Presentation-Abstraction-Control, будет рассказано далее в статье.

Шаблон Model-View-Presenter

Шаблон Model-View-Presenter представляет собой вариацию шаблона Model-View-Controller и выделяет данные приложения, отображение и пользовательский ввод в специализированные компоненты.

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

Шаблон Taligent Model-View-Presenter

Обзор

Шаблон Taligent Model-View-Presenter отделяет данные, спецификации данных, манипуляции над данными, координацию приложения, взаимодействие с пользователем и визуализацию в специализированные компоненты.

Происхождение и мотивация

Шаблон MVP был построен на программной модели Taligent, которая сама была подвержена влиянию оригинального шаблона Smalltalk-80 MVC. Впервые шаблон был формально описан в 1996 Майком Потелом, который в то время работал на Taligent, Inc. Taligent была основана Apple Computer, Inc. как совместное предприятие с IBM (в последствии с Hewlett Packard), а позже, в 1995, она стала дочерней компанией IBM. Многие элементы оригинального шаблона MVP обрели ясность в Apple под руководством Лэри Теслера, который ранее работал в Xerox PARC, где он был одним из участников дизайна и реализации Smalltalk.

Хотя основные элементы шаблона были использованы Taligent в 1992-1994 гг., пока Taligent, Inc. не была куплена IBM в 1995 и Майк Потел впервые предложил название Model-View-Presenter для описания архитектуры программной модели Taligent, сам шаблон не был. Потел говорит о Arn Schaeffer, Dave Anderson и David Goldsmith, как о главных участниках программной модели Taligent, которая послужила основой шаблона MVP (3).

Структура

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

Компоненты

Модель отвечает за данные и бизнес функциональность приложения.

Наборы являются компонентами, которые специфицируют порции данных Модели для воздействия. Примерами могут быть наборы строк, колонок или элементом, которые удовлетворяют некоторому критерию.

Команды - это компоненты, определяющие операции над данными. Примеры команд: удаление, печать, сохранение данных Модели.

Представлением является визуализация Модели и включает в себя окна и элементы управления, используемые в приложении.

Интеракторы - компоненты, отвечающие за отображение сообщений пользователя на операции над Моделью. Например, движения мыши, клавиатурный ввод.

Презентер является компонентом, который организовывает взаимодействие всех остальных компонент приложения. Среди его обязанностей - создание Моделей, Наборов, Команд, Представлений и Интеракторов, а также управление ходом работы приложения.

Взаимодействия

Самые существенные различия между шаблонами Taligent Model-View-Presenter и Model-View-Controller касаются Презентеров и Интеракторов.

Презентер выступает, как общее управление определенной подсистемой приложения. Он поддерживает жизненный цикл и взаимосвязи между Представлениями, Интеракторами, Командами, Наборами и Моделью. Обязанность по перехвату событий от пользователя ложиться на Интеракторы, поэтому Презентеры не требуются для каждого элемента управления на Представлении, как требовались Контроллеры в Smalltalk-80.

Интеракторы напоминают Контроллеры Smalltalk-80. Эти компоненты реагируют на сообщения пользователя, используя соответствующие Команды и Наборы Модели.

Шаблон Dolphin Smalltalk Model-View-Presenter

Обзор

Шаблон Dolphin Smalltalk Model-View-Presenter выделяет данные приложения, отображение и логику отображения в специализированные компоненты - Модель, Представление и Презентер. Команда Dolphin Smalltalk упростила шаблон Taligent MVP путем удаления Интеракторов, Команд и Наборов из формального описания. Это, в свою очередь, упростило Презентер путем замены роли управления определенными подсистемами приложения на посредничество между Моделью и Представлением.

Происхождение и мотивация

Шаблон Dolphin Smalltalk Model-View-Presenter был адаптирован из шаблона Taligent Model-View-Presenter для решения проблем гибкости в команде разработчиков Dolphin, касающиеся разделения представления и домена приложения. Команда рассматривала вариацию шаблона MVC, используемую в ParcPlace Systems' VisualWorks. Хотя команда Dolphin изначально рассматривала дизайн VisualWorks MVC, позже она была разочарована установленной Моделью Приложения, чья сложность время от времени искушала разработчиков разрешить модели использовать представление напрямую. Также команда выяснила, что MVC-концепция Контроллера, первичной целью которого была реакция на пользовательские сообщения, не сочеталась с платформами разработки, где базовые элементы управления обрабатывали пользовательский ввод самостоятельно. После знакомства с шаблоном Taligent MVP, команда Dolphin сделала вывод, что он больше удовлетворял их задачам. Не смотря на преимущества шаблона Taligent MVP, команда ошибочно верила, что Taligent вывела свой шаблон из реализации VisualWorks’ MVC и устранила использование Модели Приложения путем перемещения логики представления из Модели в Презентер. Они описали это, как Поворот Триады, хотя это не описывает разницу между шаблонами Taligent MVP и оригинальным Smalltalk-80 MVC. По этой причине, они видели Презентер, как замену Модели Приложения из VisualWorks’ MVC, нежели как эволюцию Контроллера Smalltalk-80 MVC. Результирующий шаблон, реализованный командой Dolphin Smalltalk, был лишен большинства компонентов, которые выделяли оригинальный MVP от MVC. С другой стороны, были представлены отличительные качества.

Структура

Следующая диаграмма изображает структуру шаблона Dolphin Smalltalk Model-View-Presenter:

Компоненты

Модель отвечает за данные и бизнес логику приложения.

Представлением является визуализация Модели и включает в себя окна и элементы управления, используемые в приложении.

Презентер - это компонент, который содержит логику представления Модели.

Взаимодействия

В контексте шаблона Dolphin MVP, Представления перехватывают сообщения пользователя, сгенерированные операционной системой. Этот выбор был результатом разработки для ОС Microsoft Windows, чьи базовые элементы управления покрывали большую часть функционала контроллера. В немногих случаях Представление отвечало на пользовательские сообщения обновляя напрямую Модель, но, в большинстве случаев, события делегировались Презентеру. Описание Dolphin Smalltalk предполагает, что Представление только делегирует события, когда требуются обновления Модели, таким образом оставляя всю логику отображения Представлению.

Как и в шаблоне Taligent MVP, существует единственный Презентер, обрабатывающий обновления Модели для конкретного Представления.

Как и в шаблоне Model-View-Controller, Представление уведомляется об изменениях Модели при помощи шаблона Обозреватель и отвечает обновлением релевантных частей экрана.

Dolphin Smalltalk MVP и Smalltalk-80 MVC

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

В контексте оригинального шаблона Model-View-Controller ключевой задачей Контроллера был перехват пользовательского ввода. Роль Контроллера по обновлению Модели была по большей части побочным эффектом этой функции, нежели неотъемлемой частью.

В контексте шаблона Dolphin Smalltalk Model-View-Presenter, наоборот, ключевой целью Презентера было обновление Модели. Роль Презентера по перехвату сообщений, делегированных Представлением, была побочным продуктом этой функции, нежели неотъемлемой частью.

Частью оригинальной идеи, которая привела к разработке шаблона MVC, было разделение пользовательского интеллектуального отображения данных (Модели) и логики, которая позволяла пользователю взаимодействовать с этим представлением (Редактор). Это считали разделением Модель\Редактор (4). Так как задачи по отображению данных на экране технически сильно отличались от задач интерпретации пользовательского ввода, объединение их в один объект вносило излишнюю сложность. Поэтому, задачи ввода и выводы были разделены по Контроллерам и Представлениям. Поскольку Контроллеры получили обязанности Редактора, логично, что они также стали ответственными за обновление Модели по причине пользовательского ввода.

В рамках шаблона Dolphin Smalltalk MVP, роль перехвата пользовательского ввода была возложена на Представление. Это эффективно устранило начальную потребность в Контроллерах и Интеракторах. Хотя команда Taligent видела оригинальную идею Презентера, как продвижение Контроллера на уровень приложения, команда Dolphin ошибочно расценивала его, как замену Модели Приложения VisualWorks и поддерживала Презентер, как посредствующий компонент в триаде.

Итак, хотя шаблоны Dolphin Smalltalk MVP и Smalltalk-80 MVC могут казаться похожими на первый взгляд, Презентеры и Контроллеры отличаются целью, для достижения которой их придумали.

MVP and MVC Part 1

Эта статья содержит вступление, общее представление и сравнение трех архитектурных шаблонов построения интерактивных приложений: Model-View-Controller, Model-View-Presenter и Presentation-Abstraction-Control.

Часть 1, Часть 2, TBD.

Вступление

Шаблоны MVC, MVP и PAC служат для удовлетворения требований интерактивных приложений путем разделения обязанностей (Separation Of Concerns), связанных с различными компонентами в пределах архитектуры. Несмотря на схожесть, они отличаются мотивацией и целесообразностью применения в различных ситуациях. Эта статья рассказывает о каждом шаблоне, его истории и мотивациях дизайна с целью правильного понимания и применения.

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

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

Принимая во внимание вышесказанное, можно сделать вывод, что Model-View-Controller был перенесен на язык шаблонов неадекватно. Другими словами, компоненты, заданные шаблоном MVC, не инвариантны относительно среды разработки, а большинство описаний не указывают это явно. Часто это приводит к некорректному применению шаблона.

Еще один совет при изучении и рассмотрении интерактивных шаблонов проектирования - не принимать все слишком серьезно. Многие базовые шаблоны, к примеру, разобранные в фундаментальном труде Э. Гаммы Приемы объектно-ориентированного проектирования. Паттерны проектирования, являются хорошо отточенными шаблонами, которые описывают инвариантные пути решения часто возникающих проблем. Принимая во внимание суть этих шаблонов, обычно, мы не получаем улучшения при использовании конкурирующих конструкций, направленных на решение той же проблемы. С другой стороны, углубляясь в область составных шаблонов, таких как шаблоны интерактивных приложений, модели, стили и пр., изучение таких конструкций пожет показаться просмотром документального фильма о истории самолетов. Это не Контроллер на последнем снимке?

Лучше всего думать об архитектурных шаблонах в сфере научного исскуства. Интерактивные архитектурные шаблоны не являются эквивалентами Закона Тяготения Ньютона. Они лишь представляют собой эволюционирующую попытку достигнуть наилучшей модели, которая удовлетворяет требованиям сегодняшнего дня.

В итоге, при выборе одного шаблона из множества, важно рассматривать их в контексте решения конкретной проблемы, а не, обезопасив пальцы за лямки спецодежды, заявлять "Я использую такие и такие шаблоны". Использование шаблона должно стать последствием возникновения проблемы, для которой есть готовое решение, а не последствием выбора шаблона с последующим подгоном проблемы. Вместе с тем, продолжим.

Шаблон Model–View-Controller

Обзор

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

Происхождение и Мотивация

Шаблон MVC был изначально придуман в 1978-79 Тригвом Ринскаугом и его изначальной целью было обеспечение пользователя интерфейсом, который позволяет производить манипуляции над многими вариантами отображения данных, как сущностей реального мира. Первоначально шаблон был упомянут, как Thing-Model-View-Editor, а потом Ринскауг и его коллеги сошлись на имени Model-View-Controller (1). Модифицированная версия дизайна Доктора Ринскауга была реализована, как часть библиотеки Xerox PARC под Smalltalk-80. Описание этой реализации можно найти в работе Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC).

Структура

Следующая диаграмма отображает структуру шаблона Model-View-Controller:

Хотя некоторые описания шаблона MVC отображают неявную асоциацию из Представления к Контроллеру, оригинальная реализация MVC в Smalltalk-80 спаривала Представление и Контроллер (2).

Компоненты

Под Моделью подразумевают данные и безнес функции приложения. Они часто имеют вид Доменной Модели, где объекты моделируют сущности реального мира путем олицетворяя их свойства и поведение.

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

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

Взаимосвязи

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

Модель представляет собой состояние, структуру и поведение отображаемых данных, которыми манипулирует пользователь. Модель не содержит прямой ссылки на Представление или Контроллер, Модель может быть модифицирована Представлением, Контроллером или другими объектами системы. Когда необходимо уведомить Представление или Контроллер, Модель использует шаблон Observer для отправки сообщений об изменившихся данных.

Компоненты Представление и Контроллер работают сообща чтобы дать пользователю возможность видеть Модель и взаимодействовать с ней. Каждое Представление сопоставлено с единственным Контроллером и каждый Контроллер с единственным Представлением. И Представление и Контроллер имеют прямую ссылку на Модель.

В реализации Smalltalk-80 и Представление и Контроллер содержали прямые ссылки друг на друга, хотя ссылка из Представления на Контроллер была по большей части побочным результатом реализации, нежели унаследованной частью шаблона MVC. Ссылка использовалась не для делегирования пользовательского ввода, перехваченного Представлением, Контроллеру, как в случае с шаблоном Dolphin Smalltalk Model-View-Presenter, а использовалась Представлением для инициализации контроллера ссылкой на себя, а также главным Колнтроллером для нахождения активного Контроллера в иерархии Представлений.

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

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

Недопонимание MVC

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