Время прочтения: 3 мин.

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

Начнем краткое путешествие в MVC и давайте сначала дадим какое-нибудь определение, что это такое. Может, назовем паттерном? (шаблон проектирования) или определим его как-то иначе?! По словам Мартина Фаулера (википедия), MVC — это набор архитектурных принципов и идей для построения систем. Как определить это — решите для себя сами в конце. Давайте же теперь посмотрим, что это такое.

Основная идея данной концепции — разделить бизнес-логику приложения, данные и визуализацию. Применяется для независимого изменения каждой части от другой.

Теперь разберем, что означают буквы в этой аббревиатуре?!:

  • M-Model-> Представляет данные и методы работы с ними. Для более простого понимания, я бы описал это, как стандартный класс с полями и методами, и реализующие ООП (объектно-ориентированное программирование).
  • V-View-> Отвечает за отображение данных. Формируется стандартная HTML страница для взаимодействия с пользователем.
  • C-Controller-> Контролирует и направляет данные от пользователя к системе и наоборот.

Разобравшись с тем, что значит каждая буква и за что она отвечает, предлагаю посмотреть, как это работает.

Сайт показывает пользователю страницу сайта(View) с различным наполнением.

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

  • прием запросов;
  • анализ запросов;
  • выбор следующего действия.

Все остальное заносит в них mauvais ton. И как раз самая часто встречаемая ошибка — добавление функций и обработки в контроллеры, а модели рассматривать только как данные и добавление их. Эта ошибка даже получила определение\название «Fat Stupid Ugly Controllers» («Толстые, тупые, уродливые контроллеры»), можете найти эту инфу в интернете, меня позабавило. На Хабре есть коротенькая статейка 6 вещей, которые не стоит делать в ASP.NET контроллерах.

Что нам дает применение этой идеи?

  1. Возможность реализации связей Model-Model, Model-View: один к одному, один ко многим, многие ко многим. Так, например, можно одну модель показать в различных вариациях: таблицах, графах и т.д.
  2. Возможность разделить разработку между разработчиками фронта и бэка, что более продуктивно по времени разработки.
  3. Не затрагивая кода во вьюшке, можно изменить реакцию на действия, поменяв в контроллере.
  4. При правильном применении дает простое поддержание кода и легкую расширяемость.

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