Вместо введения
Иногда начинаешь рассказывать о чем-нибудь небольшом. Потом думаешь что надо добавить отсутствующие детали, развивать тему и, в итоге, получается практически учебник. Так вышло у меня в этот раз. Началось все с небольшой заметки о ненавязчивом JavaScript. Поскольку он связан с проверкой данных… В итоге получился учебник по Microsoft ASP.NET MVC 3.
Что такое MVC?
Аббревиатура MVC расшифровывается как Model-View-Controller (Модель-Представление-Контроллер). Это архитектура построения приложения, в рамках которой оно разделяется на три компонента:
- Модель (Model) – предоставляет данные для Представлений в ответ на запросы Контроллера, содержит бизнес-логику приложения.
- Представление (View) – отвечает за пользовательский интерфейс, отображает данные, полученные от Модели.
- Контроллер (Controller) – обрабатывает команды пользователя, определяет Модели для работы и связывает ее с Представлением.
Бизнес-логика, расположенная в Модели, включает все правила и алгоритмы, связанные с предметной областью решаемой задачи. Проще говоря – это ядро создаваемого приложения, которое может быть как банковским клиентом, так и онлайн игрой или блогом.
Рассматриваемая архитектура подразумевает, что изменения в любом из компонентов оказывают минимальные воздействия на остальные части.
Несколько упрощая, работу MVC приложения можно описать следующим образом:
- команда (уведомление о нажатии кнопки, запроса адреса сайта и т. д.) передается Контроллеру;
- Контроллер, исходя из полученных данных, определяет и вызывает Модель;
- Модель, на основе заложенной в нее бизнес-логики, формирует набор данных;
- Контролер выбирает Представление и связывает его с данными (Моделью);
- Представление отображает данные пользователю.
Зависимости между компонентами шаблона
Контролер играет роль связующего звена между Моделью и Представлением. При этом он стремиться как можно меньше знать о подробностях их реализаций. Его задача определить Модель для обработки полученной команды и Представление, которое будет получить итоговые данные.
Представление, зависит от Модели, т.к. полагается на получаемые от нее данные.
А вот Модель не зависит ни от Представления ни от Контроллера. Это позволяет вести разработку Модели независимо, а так же создавать для нее несколько Представлений.
Результат применения MVC
- Уменьшается зависимость между частями приложения, что увеличива��т его гибкость;
- Появляется возможность разрабатывать тесты для компонентов приложения, т.е. использовать технику разработки через тестирования (Test-Driven Development или сокращенно TDD).
Сказанного выше достаточно, чтобы начать использовать архитектуру MVC в разработках. Но в начале давайте посмотрим на возможные ошибки ее применения.
Ошибки, при использовании MVC
Перегруженный Контроллер
Некоторые разработчики ошибочно трактуют Модель только как средство доступа к базе данных. В результате бизнес-логика переходит в Контроллер, что в корне противоречит архитектуре MVC.
Стоит помнить, что Модель это не только доступ к данным, но и логика приложения, проверка получаемых от пользователя данных и т. д. В свою очередь, Контроллер – связующее звено между ней, Представлением и пользователем.
Перегруженная Модель
Другим заблуждением является попытка перенести всю логику в Модель. Подобную ошибку часто можно встретить при разработке веб-приложений. В этом случае Представление стараются превратить в простой шаблон, доступный для редактирования любому верстальщику. При этом логика элементов пользовательского интерфейса из Представлений перемещается в Модель или, иногда, в Контроллер.
Данный подход ошибочен с точки зрения архитектуры MVC, т.к. нарушается четкое разделение компонентов: Модель становится зависима от Представления.
При правильном подходе, Логика пользовательского интерфейса должна находиться в Представлениях. Но при этом важно корректно разделить ее и бизнес-логику.