Andrey on .NET

Вместо введения

Иногда начинаешь рассказывать о чем-нибудь небольшом. Потом думаешь что надо добавить отсутствующие детали, развивать тему и, в итоге, получается практически учебник. Так вышло у меня в этот раз. Началось все с небольшой заметки о ненавязчивом JavaScript. Поскольку он связан с проверкой данных… В итоге получился учебник по Microsoft ASP.NET MVC 3.

Что такое MVC?

Аббревиатура MVC расшифровывается как Model-View-Controller (Модель-Представление-Контроллер). Это архитектура построения приложения, в рамках которой оно разделяется на три компонента:

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

Бизнес-логика, расположенная в Модели, включает все правила и алгоритмы, связанные с предметной областью решаемой задачи. Проще говоря – это ядро создаваемого приложения, которое может быть как банковским клиентом, так и онлайн игрой или блогом.

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

Несколько упрощая, работу MVC приложения можно описать следующим образом:

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

Зависимости между компонентами шаблона

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

Представление, зависит от Модели, т.к. полагается на получаемые от нее данные.

А вот Модель не зависит ни от Представления ни от Контроллера. Это позволяет вести разработку Модели независимо, а так же создавать для нее несколько Представлений.

Результат применения MVC

• Уменьшается зависимость между частями приложения, что увеличивает его гибкость;
• Появляется возможность разрабатывать тесты для компонентов приложения, т.е. использовать технику разработки через тестирования (Test-Driven Development или сокращенно TDD).

Сказанного выше достаточно, чтобы начать использовать архитектуру MVC в разработках. Но в начале давайте посмотрим на возможные ошибки ее применения.

Ошибки, при использовании MVC

Перегруженный Контроллер

Некоторые разработчики ошибочно трактуют Модель только как средство доступа к базе данных. В результате бизнес-логика переходит в Контроллер, что в корне противоречит архитектуре MVC.

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

Перегруженная Модель

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

Данный подход ошибочен с точки зрения архитектуры MVC, т.к. нарушается четкое разделение компонентов: Модель становится зависима от Представления.

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