Основы. Часть 1 - Шаблон MVC

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

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

Что такое MVC?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии (15) -

Александр 04.03.2011 14:26:46

> Контролер, получив данные, выбирает Представление и передает ему их;
Вы привели только частный случай взаимодействия. Ведь основной вариант когда контролер лишь оповещает представление что данные готовы и оно само их выбирает для отрисовки. В вашем же процессе получается, что представление полностью изалированно от модели а контролер фактически выполняет роль посредника. Тогда уж и шаблон следует называть "Посредник". Если такое поведение характерно для ASP.NET MVC то следует это указать в статье.

@ Александр: С замечанием согласен. Изменил текст.

Ринат 20.08.2011 21:29:26

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

Да, именно так.

Артур 01.11.2011 17:04:50

Ринат :
Андрей, подскажите, правильно ли я понимаю что в MVC Модель включает себя и Бизнес-логику(алгоритм, правила обработки) и Слой данных(взаимодействие с СУБД) в терминах трехслойной архитектуры, т.е. Модель это не просто несколько классов с кучей публичных свойств...

Скорее модель это только бизнесс слой, который уже в себя включает  и Слой данных  (в идеальном мире через зависимости). Т.е. контроллер нарямую со слоем данных работать на должен.

Насчет
несколько классов с кучей публичных свойств
это больше похоже на ViewModel - класс, который представляет только и только то, что нужно для отображения во View (обычно бизнесc модель содержит немного больше, чем нужно знать View).В простейших случах это примитивный маппинг свойств (некий DTO объект),в более сложных случаях это трансформация бизнесс модели в форму, более удобную для отображения во View.

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

Меня этот вопрос очень волнует, в более менее сложном приложении контроллер не должен обращаться к БД через чтобы то ни было (DbContext или другую часть DAL уровня), а должен обращаться через бизнес объекты. С другой стороны создавать полную копию иерархии всех объектов DAL в BLL слишком бессмысленно, не могу никак найти оптимальное правильное понимание применения MVC и трёхслойной архитектуры вместе

Димка 24.01.2012 16:34:17

спасибо огромное, великолепная книга-инструкция!

@ Alex: Здесь коротким ответом наверное не обойдешься. Но постараюсь изложить суть.

Если у вас методы в DAL дублируют методы бизнес логики, то возможно (возможно!) вы перенесли логику в DAL. Ну или логика очень простая ("взять из базы запись c id = K").

Но если посмотреть дальше, и использовать в DAL не просто репозиторий, а его вариант с спецификациями или query, то реализация самих "запросов" как раз будет в бизнес логике (где ей и место). А DAL будет заниматься именно работой с БД.

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

@ Димка: Пожалуйста.

MVC частный случай реструктуризации (один поток влияет на другой поток на выходе третий поток)

@ Andruha: Вы путаете рефакторинг (реструктуризацию) и шаблон проектирования.

@ Andrey:

Я не путаю, я о том что MVC это не только архитектура построения приложения в том виде в котором вы ее описали, это нечто более глобальное. Допустим есть таблица в эксель я накладываю на нее фильтр, и часть строк перестает отображаться, получается другая таблица. Таким образом исходная таблица это модель, фильтр - контроллер, а полученая таблица - представление. Или тоже самое можно сказать про обработку массива в цикле с передачей данных удовлетворяющих условию в новый массив.

@ Andruha: Поскольку все шаблоны достаточно абстрактны, то их можно "применить" и увидеть много где. Те же шаблоны ООП можно встретить в реальных предметах. Вот только в данном блоге речь идет о их определенном контексте.

@ Andrey: Ну незнаю стоит ли применять шаблоны или видеть их в реальных предметах )), я обычно поступаю наоборот. Пишу тут программу дак у меня одна модель является контроллером другой модели, а может и наоборот. Вобщем все написаное имеет место быть, и комунибудь пригодится. Удачи в программировании.

Andruha: Ну незнаю стоит ли применять шаблоны или видеть их в реальных предметах

Адаптером розетки не пользовались ни разу? В общем, это я к тому, что излишне обобщать не стоит. А то уже начинаете контроллеры в моделях и т.д. Smile

Pingbacks and trackbacks (3)+

Добавить комментарий