Model-View-Controller (12. Шаблоны группы Model-view-controller)

'гЛоеей/~евг-Сопггоаег в .Нег 08Д1.12 1 «показать меню;.ф соовщенмй 187 Ж- оценка 1547 ~+4/-2) ",'. фа оценить ''г,сч '~!. у:..З' и:.гвз ~~ $- Оргэограгэня Автор: Иван Бодягин 'Пзе й5Ргв Свгоир Кс гочнию К5Рй Иадаз1пе Ф2-2ООб Опубликова .о: 2б.07.2000 Исправлено: 30.06.2007 Версия текста: 1.1 Введение «Оригинальный» ИггС Недостатки МчС и Оосигпепг-У1ея ИодеИЛе1аг-Ргевепйег Моае1 РГЕ8ЕПГЕГ Ч'еиг Почему интерфейс7 Отличия от МЧС Заключение Что почитать Демонстрационный проект В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Моае1-Ч1еьт-Соп~го11ег или сокращенно МЧС, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте.

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

Мое«1-Ч~ев-Соп1ю!!ег в .Не1 Несмотря на то, что, как уже говорилось, под аббревиатурой МЧС обычно понимают целое семейство паттернов, можно выделить первоначальный вариант данного архитектурного решения. На данный момент, применение МЧС в оригинальном виде вряд ли будет оправдано, по разным причинам, однако эволюцию паттерна лучше проследить с самого начала... Впервые паттерн МЧС появился в языке 5п1а1!Та1К в конце семидесятых.

Собственно задача была хорошо всем знакомая, надо было придумать архитектурное решение, которое позволяло бы манипулировать графическими представлениями данных некоего приложения, таким образом, чтобы изменение Представления этих данных не влияло на бизнес-логику и данные (Модель) приложения, а так же, чтобы была возможность иметь несколько Представлений для одной Модели. Таким решением и стал паттерн МЧС, идея которого родилась в недрах Хегох РАЙК, и получила свое первое публичное упоминание в документации к 5гпа1ГГа1К'80.

В классическом варианте, МЧС состоит из трех частей, которые и дали ему название. Под Моделью, обычно понимается часть содержащая в себе функциональную логику приложения, иными словами то, что мы обычно называем «Воз!пеев Ьауег», «Бизнес-слой» или «Слой бизнес логики». Как именно организован этот слой, по большому счету не важно, однако есть ряд ключевых моментов, на которых мы остановимся позднее.

Основная цель паттерна — сделать так, чтобы Модель была полностью независима от остальных частей и практически ничего не знала об их существовании, что позволило бы менять и Контроллер и Представление модели, не трогая саму Модель и даже позволить функционирование нескольких экземпляров Представлений и Контроллеров с одной Моделью одновременно. Вследствии чего, Модель ни при каких условиях не может содержать ссылок на объекты Представления или Контроллера. Обычно различают несколько типов паттернов в зависимости от роли модели. Равв1че Моде! (пассивная модель) — Модель не имеет вообще никаких способов воздействовать на Представление или Контроллер и только используется ими в качестве источника данных для отображения.

Все изменения модели отслеживаются Контроллером и он же отвечает за перерисовку Представления, если это необходимо. Рече моде! (активная модель) - мьдель имеет возможность оповестить предсгпевпение о том, что в ней произошли некие изменения, и Представление может эти изменения отобразить. Как правило, механизм оповещения реализуется на основе паттерна ОЬзегуег (обозреватель), Модель просто бросает сообщение, а Представления, которые заинтересованы в оповещении, подписываются на эти сообщения, что позволяет сохранить независимость Модели как от Контроллера так и от Представления, не нарушая тем самым основного свойства паттерна. Классической реализацией паттерна МЧС принято считать версию именно с активной Моделью.

Ьттр:Оеп.я1К!редььогй/а!И/ОЬзегуег раттегп Ь1тр:ОдоГастогу.сот/Райегпз/РагтегпОЬзеп ег.азрх В обязанности Представления входит отображение данных полученных от Модели. Обычно Представление имеет свободный доступ к Модели и может брать из нее данные, однако это доступ только на чтение ничего менять в Модели или даже просто вызывать методы 08.01.12 Мосей/1ев-Сои1ю8ег в .Не1 приводящие к изменению ее внутреннего состояния, Представлению позволять нельзя. В случае активной Модели, Представление может подписаться на события изменения Модели и перерисовываться, забрав измененные данные, при получении соответствующего оповещения.

Для взаимодействия с Контроллером, представление, как правило, реализует некий интерфейс, известный Конл1роплеру, что позволяет менять представления независимо и иметь несколько представлений на Контроллер. Вообще, подмена или изменение Представления самая часто встречающаяся задача, по сути это и есть та причина по которой придумывают различные паттерны разделения Модели и Представления.

В задачи Контроллере входит реакция на внешние раздражители и изменение Модели и/ или Представления в соответствии с заложенной в него логикой. Один Контроллер может работать с несколькими Представлениями, в зависимости от ситуации, взаимодействуя с ними через некий заранее известный интерфейс, который эти Представления реализуют. Важный нюанс, в классической версии МЧС Контроллер не занимается передачей данных из Модели в Представление и не является медиатором (Мед~асог) между Моделью и Представлениями.

ПРИМЕЧАИИЕ Стоит упомянуть, что МЧС ни коим образом не определяет каким именно способом Модель взаимодействует с данными и как реализован уровень доступа к данным— это лежит вне зоны отве1ственности данного паттерна. Таким образом, типичная схема взаимодействия компонентов паттерна выглядит примерно так: Контроллер перехватывает событие извне и в соответствии с заложенной в него логикой, реагирует на это событие изменяя Модель, посредством вызова соответствующего метода Модели.

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

Следующим этапом развития МЧС стал паттерн Ооситепс-Ч!еа, хорошо известный по таким библиотекам как ТцгЬо Ч1зюп (Разса! 6.0, ох ностальгия, М1сгозо(т Еоипдабюп С!азз ЫЬгагу и многих других вплоть до УУ~пРоггпз Моде!!-Ч!ев-Сопка!!ег в .Не! ПРИМЕ«1АИИЕ Строго говоря, утверждать, что эти библиотеки реализуют именно Роса/пеп1-Ч!еу/ была бы не совсем верно, в конце-концов зто все~о лишь библиотеки и использовать их можно па разному, вернее было бы сказать, что эти библиотеки склоняют к использованию МЧС именно в таком виде, как примерами из документации, так и собственной архитектурой.

В этой версии МЧС Контроллер интегрирован в Представление, что ни в коей мере не является нарушением основной идеи паттерна. Сделано это было по многим причинам, прежде всего, отделение Контроллера от Представления, действительно не самая ключевая часть паттерна. Другой причиной являлось появление, графических оболочек встроеных в ОС, что позволяло не рисовать графические элементы (контролы) пользовательского интерфейса под каждый проект, а использовать готовые, предоставляемые платформой посредством соответствующего АР1, но дело в том, что в этих оболочках функции Контроллера уже были интегрированы в контролы (которые и являются Првдстввпениямо или же частями оного).

Свою роль сыграло и появление визуальных графических оболочек встроеных в среду программирования (так называемые и/!г!де~-Ьазед среды пользовательского интерфейса), поскольку код сгенеренный этими оболочками, естественно, использовал готовые графические элементы платформы и, как следствие, опять-таки провоцировал разработку в стиле ОасигпепФ-Ч!еа. Ю/1пГогптз, в купе с Ч1ьца! 5~иа10, так же являются примером такой среды. У той же М1сговой, которая выкладывает довольно много статей по архитектурным решениям в свободный доступ, есть несколько публикаций и по МЧС, и там можно легко заметить, что все примеры чистого МЧС даются не на основе УУ/пРогптз приложений, а на примере АВР.МЕТ, где, в отличии от УУ1проггпз, есть относительно четкое разделение между Контроллерам и Првдставпвновм, про УУ1пРоппв же есть только упоминание о том, что, как правило, в подобного рода приложениях Контроллер интегрирован в Представление.

В целом МЧС и Васи/пел~-Ч/еи/, как его логическое продолжение вполне адекватные паттерны для ряда задач, и с успехом применяются в большем количестве проектов, но в то же время обладают и рядом недостатков. Прежде всего, чистый МЧС плохо подходит для сред типа Ч/1пРоггпз, поскольку, как уже говорилось выше, код, который порождают среды и библиотеки провоцирует интегрировать Контроллер в Првдстввпвнов. Получающийся в результате вариант паттерна в виде Оосц/пепс-Ч1е!и, в принципе, вполне приемлемое решение, однако далеко не всегда.

Дело в том, что логика Конгпроппвра, на самом деле, практически не зависит от типа Представления и сама по себе довольно неплохо поддается тестированию. А встраивание этой логики в Представление, в случае разных типов Представлений, приводит к дублированию кода и практически исключает возможность внятного тестирования этой логики, так как тестирование пользовательского интерфейса — это отдельная головная боль. Да и в целом, реализация логики контроллера вместе с представлением порождает довольно кашеобразную конструкцию из смеси автогенеренного и ручного кода Првдстввпвноя и кода логики Контроллера, который довольно сложно поддерживать. С появлением ЕЮ/ 2.0 и Раг~1а1-классов стало несколько легче, но проблема все равно актуальна.

Если же попытаться выделить Контроллер «в лоб»ч то можно нарваться на следующие неприятности... В оригинальном паттерне именно контроллер должен реагировать на внешние события, однако в коде порожденном дизайнером Ч!зиа1 5~ис!10 все обработчики уже встроены в Представление. Приходится либо уходить от автогенеренного кода и готового дизайнера форм, что вряд ли можно назвать адекватным решением, либо как-то пытаться адаптировать сгенерированный дизайнером код под вынесение обработчика событий во внешний контроллер.