Model-View-Controller: различия между версиями
[непроверенная версия] | [непроверенная версия] |
NapalmBot (обсуждение | вклад) м CheckWiki: исправление внешних ссылок. |
Удалена дублирующаяся информация |
||
Строка 20: | Строка 20: | ||
* '''''Представление''''' (''View'') отвечает за отображение данных модели пользователю, реагируя на изменения модели{{sfn|Обобщённый Model-View-Controller|2007}}. |
* '''''Представление''''' (''View'') отвечает за отображение данных модели пользователю, реагируя на изменения модели{{sfn|Обобщённый Model-View-Controller|2007}}. |
||
* '''''Контроллер''''' (''Controller'') интерпретирует действия пользователя, оповещая модель о необходимости изменений{{sfn|Обобщённый Model-View-Controller|2007}}. |
* '''''Контроллер''''' (''Controller'') интерпретирует действия пользователя, оповещая модель о необходимости изменений{{sfn|Обобщённый Model-View-Controller|2007}}. |
||
Впервые описан норвежцем [[Реенскауг, Трюгве|Трюгве Ринскаугом]] в 1978 году{{sfn|Обобщённый Model-View-Controller|2007}}. |
|||
== История == |
== История == |
Версия от 06:10, 6 июля 2017
Модель Представление Контроллер | |
---|---|
Model-View-Controller | |
Структура |
|
Описан в Design Patterns | Нет |
Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо[1].
- Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя свое состояние[1].
- Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели[1].
- Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений[1].
История
Концепция MVC была описана Трюгве Реенскаугом в 1978 году[1][2], работавшем в научно-исследовательском центре «Xerox PARC» над языком программирования «Smalltalk». Позже, Стив Бурбек реализовал шаблон в Smalltalk-80[1][3][4].
Окончательная версия концепции MVC была опубликована лишь в 1988 году в журнале Technology Object[5].
Впоследствии, шаблон проектирования стал эволюционировать. Например, была представлена иерархическая версия HMVC; MVA, MVVM[6][7][8].
После внедрения компанией Apple технологии WebObjects, реализованных на Objective-C, стало популяризировать шаблон и в вебе[источник не указан 2901 день].
Когда WebObjects портировали на Java, шаблон стал популярен и там. Более поздние фреймворки вроде Spring (октябрь 2002 года) всё ещё имеют реализацию MVC[источник не указан 2901 день].
Дальнейший виток популярности привнесло развитие фреймворков, ориентированных на быструю развёртку, на языках Python и Ruby, Django и Rails, соответственно[источник не указан 2901 день]. На момент 2017 года, фреймворки с MVC заняли заметные позиции по отношению к остальным фреймворкам без этого шаблона[9].
Различия описания концепции шаблона
С развитием объектно-ориентированного программирования и понятия о шаблонах проектирования — был создан ряд модификаций концепции MVC, которые при реализации у разных авторов могут отличаться от оригинальной. Так, например, Эриан Верми в 2004 году описал пример обобщённого MVC[10].
В предисловии к диссертации «Naked objects» Ричарда Поусона (Richard Pawson), — Трюгве Реенскауг упоминает свою неопубликованную наиболее раннюю версию MVC, согласно которой[11]:
- Модель относилась к «разуму» пользователя;
- Под представлением имелся в виду редактор, позволяющий пользователю просматривать и обновлять информацию;
- Контроллер являлся инструментом для связывания представлений воедино и применялся пользователем для решения его задач.
Назначение
Основная цель применения этой концепции состоит в отделении бизнес-логики (модели) от её визуализации (представления, вида). За счёт такого разделения повышается возможность повторного использования кода. Наиболее полезно применение данной концепции в тех случаях, когда пользователь должен видеть те же самые данные одновременно в различных контекстах и/или с различных точек зрения. В частности, выполняются следующие задачи:
- К одной модели можно присоединить несколько видов, при этом не затрагивая реализацию модели. Например, некоторые данные могут быть одновременно представлены в виде электронной таблицы, гистограммы и круговой диаграммы;
- Не затрагивая реализацию видов, можно изменить реакции на действия пользователя (нажатие мышью на кнопке, ввод данных) — для этого достаточно использовать другой контроллер;
- Ряд разработчиков специализируется только в одной из областей: либо разрабатывают графический интерфейс, либо разрабатывают бизнес-логику. Поэтому возможно добиться того, что программисты, занимающиеся разработкой бизнес-логики (модели), вообще не будут осведомлены о том, какое представление будет использоваться.
Концепция
В разделе не хватает ссылок на источники (см. рекомендации по поиску). |
Концепция MVC позволяет разделить модель, представление и контроллер на три отдельных компонента:
Модель
Модель предоставляет данные и методы работы с ними: запросы в базу данных, проверка на корректность. Модель не зависит от представления — не знает как данные визуализировать — и контроллера — не имеет точек взаимодействия с пользователем —, просто предоставляя доступ к данным и управлению ими.
Модель строится таким образом, чтобы отвечать на запросы, изменяя своё состояние, при этом может быть встроено уведомление «наблюдателей».
Модель, за счёт независимости от визуального представления, может иметь несколько различных представлений для одной «модели».
Представление
Представление отвечает за получение необходимых данных из модели и отправляет их пользователю. Представление не обрабатывает введённые данные пользователя[источник не указан 2898 дней].
Представление может влиять на состояние модели сообщая модели об этом.
Контроллер
Контроллер обеспечивает «связи» между пользователем и системой. Контролирует и направляет данные от пользователя к системе и наоборот. Использует модель и представление для реализации необходимого действия.
Функциональные возможности и расхождения
Поскольку MVC не имеет строгой реализации, то реализован он может быть по-разному. Нет общепринятого определения, где должна располагаться бизнес-логика. Она может находиться как в контроллере, так и в модели. В последнем случае, модель будет содержать все бизнес-объекты со всеми данными и функциями.
Некоторые фреймворки жестко задают где должна располагаться бизнес-логика, другие не имеют таких правил.
Также не указано, где должна находиться проверка введённых пользователем данных. Простая валидация может встречаться даже в представлении, но чаще они встречаются в контроллере или модели.
Интернационализация и форматирование данных также не имеет четких указаний по расположению.
Условно-обязательные модификации
Для реализации схемы «Model-View-Controller» используется достаточно большое число шаблонов проектирования (в зависимости от сложности архитектурного решения), основные из которых — «наблюдатель», «стратегия», «компоновщик»[12]:
Наиболее типичная реализация — в которой вид отделён от модели путём установления между ними протокола взаимодействия, использующего «аппарат событий» (обозначение «событиями» определённых ситуаций, возникающих в ходе выполнения программы, — и рассылка уведомлений о них всем тем, кто подписался на получение): при каждом особом изменении внутренних данных в модели (обозначенном как «событие»), она оповещает о нём те зависящие от неё представления, которые подписаны на получение такого оповещения — и представление обновляется. Так используется шаблон «наблюдатель»;
При обработке реакции пользователя — представление выбирает, в зависимости от реакции, нужный контроллер, который обеспечит ту или иную связь с моделью. Для этого используется шаблон «стратегия», или вместо этого может быть модификация с использованием шаблона «команда»;
Для возможности однотипного обращения с подобъектами сложно-составного иерархического вида — может использоваться шаблон «компоновщик». Кроме того, могут использоваться и другие шаблоны проектирования — например, «фабричный метод», который позволит задать по умолчанию тип контроллера для соответствующего вида.
Наиболее частые ошибки
Начинающие программисты очень часто трактуют архитектурную модель MVC как пассивную модель MVC: модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику. В результате — код моделей по факту является средством получения данных из СУБД, а контроллер — типичным модулем, наполненным бизнес-логикой (см. «скрипт» в терминологии веб-программирования). В результате такого понимания — MVC-разработчики стали писать код, который Pádraic Brady (известный в кругах сообщества «Zend Framework») охарактеризовал как «ТТУК» («Толстые, тупые, уродливые контроллеры»; Fat Stupid Ugly Controllers):
Среднестатистический ТТУК получал данные из БД (используя уровень абстракции базы данных, делая вид, что это модель) или манипулировал, проверял, записывал, а также передавал данные в Представление. Такой подход стал очень популярен потому, что использование таких контроллеров похоже на классическую практику использования отдельного php-файла для каждой страницы приложения.
— [http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/ The M in MVC: Why Models are Misunderstood and Unappreciated
Но в объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД, но и вся бизнес-логика; также, модели могут инкапсулировать в себе другие модели. Контроллеры же, — как элементы информационной системы, — ответственны лишь за:
- Приём запроса от пользователя;
- Анализ запроса;
- Выбор следующего действия системы, соответственно результатам анализа (например, передача запроса другим элементам системы);
Только в этом случае контроллер становится «тонким» и выполняет исключительно функцию связующего звена (glue layer) между отдельными компонентами информационной системы.
См. также
- Model-View-ViewModel
- Model-View-Presenter
- Фасад (шаблон проектирования)
- Ruby on Rails
- ASP.NET MVC Framework
- Сравнение каркасов веб-приложений, в том числе построенных по шаблону Модель-Вид-Контроллер
Примечания
- ↑ 1 2 3 4 5 6 Обобщённый Model-View-Controller, 2007.
- ↑ Trygve M. H. Reenskaug/MVC XEROX PARC 1978-79
- ↑ Стив Бурбек. [https://web.archive.org/web/20100921030808/http://www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System].
- ↑ В. А. Савельев. Программирование Приложений в Smalltalk-80™: Как использовать Model-View-Controller (MVC).
- ↑ A cookbook for using the model-view controller user interface paradigm in Smalltalk-80, A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System (перевод В. А. Савельев)
- ↑ A cookbook for using the model-view controller user interface paradigm in Smalltalk-80 .
- ↑ Стив Бурбек. [https://web.archive.org/web/20100921030808/http://www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System].
- ↑ В. А. Савельев. Программирование Приложений в Smalltalk-80™: Как использовать Model-View-Controller (MVC).
- ↑ hotframeworks
- ↑ Vermeij. Arjan A Generic MVC Model in Java 2004
- ↑ Richard Pawson Naked objects, PhD dissertation, University of Dublin, Trinity College, 2004
- ↑ Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приёмы объектно-ориентированного проектирования. Паттерны проектирования 2001
Литература
- Адам Фримен. ASP.NET MVC 4 с примерами на C# 5.0 для профессионалов, 4-е издание = Pro ASP.NET MVC 4, 4th edition. — М.: «Вильямс», 2013. — 688 с. — ISBN 978-5-8459-1867-3.
- Джесс Чедвик и др. ASP.NET MVC 4: разработка реальных веб-приложений с помощью ASP.NET MVC = Programming ASP.NET MVC 4: Developing Real-World Web Applications with ASP.NET MVC. — М.: «Вильямс», 2013. — 432 с. — ISBN 978-5-8459-1841-3.
- Сергей Рогачев. Обобщённый Model-View-Controller // rsdn.org. — 2007.
Ссылки
- MVC простым языком — на примере автомобиля
- Сергей Бердачук. Eclipse RCP. Файловый менеджер
- Model-View-Controller в .Net
- Model-View-Controller в PHP
- Разработка встроенных приложений с использованием eSWT