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, а не за счет Контроллера. Задача последнего - быть посредником между человеком и приложением, а не между Представлением и Моделью.