Model-View-Controller ( MVC , «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо .

• Модель ( Model ) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние .
• Представление ( View ) отвечает за отображение данных модели пользователю, реагируя на изменения модели .
• Контроллер ( Controller ) интерпретирует действия пользователя, оповещая модель о необходимости изменений .

История

Концепция MVC была описана Трюгве Реенскаугом в 1978 году , работавшим в научно-исследовательском центре « Xerox PARC » над языком программирования « Smalltalk ». Позже, Стив Бурбек реализовал шаблон в Smalltalk-80 .

Окончательная версия концепции MVC была опубликована лишь в 1988 году в журнале .

Впоследствии шаблон проектирования стал эволюционировать. Например, была представлена иерархическая версия HMVC ; , MVVM .

Дальнейший виток популярности привнесло развитие фреймворков, ориентированных на быструю развёртку, на языках Python ( Django ), PHP ( Laravel ) и Ruby ( Ruby on Rails) . На момент 2017 года, фреймворки с MVC заняли заметные позиции по отношению к остальным фреймворкам без этого шаблона .

Различия описания концепции шаблона

С развитием объектно-ориентированного программирования и понятия о шаблонах проектирования — был создан ряд модификаций концепции MVC, которые при реализации у разных авторов могут отличаться от оригинальной. Так, например, Эриан Верми в 2004 году описал пример обобщённого MVC .

В предисловии к диссертации « Naked objects » Ричарда Поусона (Richard Pawson) Трюгве Реенскауг упоминает свою неопубликованную наиболее раннюю версию MVC, согласно которой :

• Модель относилась к «разуму» пользователя;
• Под представлением имелся в виду редактор, позволяющий пользователю просматривать и обновлять информацию;
• Контроллер являлся инструментом для связывания представлений воедино и применялся пользователем для решения его задач.

Назначение

Основная цель применения этой концепции состоит в отделении бизнес-логики ( модели ) от её визуализации ( представления , вида ). За счёт такого разделения повышается возможность повторного использования кода . Наиболее полезно применение данной концепции в тех случаях, когда пользователь должен видеть те же самые данные одновременно в различных контекстах и/или с различных точек зрения. В частности, выполняются следующие задачи:

1. К одной модели можно присоединить несколько видов , при этом не затрагивая реализацию модели . Например, некоторые данные могут быть одновременно представлены в виде электронной таблицы , гистограммы и круговой диаграммы ;
2. Не затрагивая реализацию видов , можно изменить реакции на действия пользователя (нажатие мышью на кнопке, ввод данных) — для этого достаточно использовать другой контроллер ;
3. Ряд разработчиков специализируется только в одной из областей: либо разрабатывают графический интерфейс , либо разрабатывают бизнес-логику . Поэтому возможно добиться того, что программисты, занимающиеся разработкой бизнес-логики ( модели ), вообще не будут осведомлены о том, какое представление будет использоваться.

Концепция

Концепция MVC позволяет разделить модель, представление и контроллер на три отдельных компонента:

Модель

Модель предоставляет данные и методы работы с ними: запросы в базу данных, проверка на корректность. Модель не зависит от представления (не знает как данные визуализировать) и контроллера (не имеет точек взаимодействия с пользователем), просто предоставляя доступ к данным и управлению ими.

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

Модель, за счёт независимости от визуального представления, может иметь несколько различных представлений для одной «модели»

Представление

Представление отвечает за получение необходимых данных из модели и отправляет их пользователю. Представление не обрабатывает введённые данные пользователя .

Контроллер

Контроллер обеспечивает «связь» между пользователем и системой. Контролирует и направляет данные от пользователя к системе и наоборот. Использует модель и представление для реализации необходимого действия.

Функциональные возможности и расхождения

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

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

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

Интернационализация и форматирование данных также не имеет четких указаний по расположению.

Условно-обязательные модификации

Для реализации схемы «Model-View-Controller» используется достаточно большое число шаблонов проектирования (в зависимости от сложности архитектурного решения), основные из которых — « наблюдатель », « стратегия », « компоновщик » .

Наиболее типичная реализация — в которой представление отделено от модели путём установления между ними протокола взаимодействия, использующего «аппарат событий» (обозначение «событиями» определённых ситуаций, возникающих в ходе выполнения программы, — и рассылка уведомлений о них всем тем, кто подписался на получение): при каждом особом изменении внутренних данных в модели (обозначенном как «событие»), она оповещает о нём те зависящие от неё представления, которые подписаны на получение такого оповещения — и представление обновляется. Так используется шаблон « наблюдатель ».

При обработке реакции пользователя — представление выбирает, в зависимости от реакции, нужный контроллер , который обеспечит ту или иную связь с моделью. Для этого используется шаблон « стратегия », или вместо этого может быть модификация с использованием шаблона « команда ».

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

Наиболее частые ошибки

Начинающие программисты очень часто трактуют архитектурную модель MVC как пассивную модель MVC: модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику . В результате — код моделей по факту является средством получения данных из СУБД , а контроллер — типичным модулем , наполненным бизнес-логикой. В результате такого понимания — MVC-разработчики стали писать код, который Падриг Брэди (известный в кругах сообщества « Zend Framework ») охарактеризовал как «ТТУК» («Толстые, тупые, уродливые контроллеры»; Fat Stupid Ugly Controllers):

Среднестатистический ТТУК получал данные из БД (используя уровень абстракции базы данных, делая вид, что это модель) или манипулировал, проверял, записывал, а также передавал данные в Представление. Такой подход стал очень популярен потому, что использование таких контроллеров похоже на классическую практику использования отдельного php-файла для каждой страницы приложения.

— [ The M in MVC: Why Models are Misunderstood and Unappreciated

Но в объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД , но и вся бизнес-логика ; также модели могут инкапсулировать в себе другие модели. Контроллеры же, — как элементы информационной системы , — ответственны лишь за:

• приём запроса от пользователя ;
• анализ запроса;
• выбор следующего действия системы, соответственно результатам анализа (например, передача запроса другим элементам системы).

Только в этом случае контроллер становится «тонким» и выполняет исключительно функцию связующего звена (glue layer) между отдельными компонентами информационной системы .

См. также

• Model-View-ViewModel
• Model-View-Presenter

Примечания

Литература

• Адам Фримен. 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 .
• Сергей Рогачев. // rsdn.org. — 2007.

Ссылки

• MVC простым языком — на от 4 июля 2015 на Wayback Machine
• Сергей Бердачук.