АРХИТЕКТУРНЫЙ ШАБЛОН ПРОЕКТИРОВАНИЯ MVC

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

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

Впервые она была описана в 1979 году, конечно же, для другого окружения. Тогда не существовало концепции веб приложения. Tim Berners Lee (Тим Бернерс Ли) посеял семена World Wide Web (WWW) в начале девяностых и навсегда изменил мир. Шаблон, который мы используем сегодня, является адаптацией оригинального шаблона к веб разработке.

Бешеная популярность данной структуры в веб приложениях сложилась благодаря её включению в две среды разработки, которые стали очень популярными: Struts и Ruby on Rails. Эти две среды разработки наметили пути развития для сотен рабочих сред, созданных позже.

Идея, которая лежит в основе архитектурного шаблона MVC, очень проста: нужно чётко разделять ответственность за различное функционирование в наших приложениях. Приложение разделяется на три основных компонента, каждый из которых отвечает за различные задачи.

Контроллер (Controller)

Контроллер управляет запросами пользователя (получаемые в виде запросов HTTP GET или POST, когда пользователь нажимает на элементы интерфейса для выполнения различных действий). Его основная функция — вызывать и координировать действие необходимых ресурсов и объектов, нужных для выполнения действий, задаваемых пользователем. Обычно контроллер вызывает соответствующую модель для задачи и выбирает подходящий вид.

Например, Products_controller будет обрабатывать все взаимодействия и входные данные из представления товаров и обновлять базу данных, используя модель товаров. Тот же контроллер будет использоваться для просмотра данных товаров.

Модель (Model)

Модель - это данные и правила, которые используются для работы с данными, которые представляют концепцию управления приложением. В любом приложении вся структура моделируется как данные, которые обрабатываются определённым образом. Модель даёт контроллеру представление данных, которые запросил пользователь (сообщение, страницу книги, фотоальбом, и тому подобное). Модель данных будет одинаковой, вне зависимости от того, как мы хотим представлять их пользователю. Поэтому мы выбираем любой доступный вид для отображения данных.

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

Например, объект User будет извлекать информацию о пользователе из базы данных, манипулировать ею, обновлять данные и помещать их обратно в базу данных или использовать ее для визуализации данных.

Вид (View)

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

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

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

С технической точки зрения, при сборке с использованием архитектуры MVC у разработчика есть следующие стратегические преимущества:

• Разделять роли в проекте становится проще. В проекте может быть бэкэнд-разработчик, работающий над логикой контроллера, и фронтенд-разработчик, который работает с представлениями. Это очень распространенный способ работы в компаниях, и наличие MVC делает процесс разделения обязанностей намного проще, чем, когда кодовая база содержит так называемый «спагетти-код».
• Стратегия MVC вынуждает разбивать файлы на логические каталоги, что облегчает поиск определенных файлов при работе над большими проектами.
• Изоляция ответственности. Например, можно вносить изменения в представления и в модели отдельно, потому что они друг от друга независимы.
• Полный контроль над URL-адресами приложений. Архитектура MVC позволяет полностью контролировать внешний вид приложения, выбирая маршруты.
• С MVC легче следовать принципу SOLID.

У архитектурного шаблона проектирования MVC есть как преимущества, так и недостатки:

• Необходимость использования большего количества ресурсов. Сложность обусловлена тем, что все три фундаментальных блока являются абсолютно независимыми и взаимодействуют между собой исключительно путем передачи данных. Controller должен всегда загрузить (и при необходимости создать) все возможные комбинации переменных и передать их в Model. Model, в свою очередь, должна загрузить все данные для визуализации и передать их во View.
• Усложнен механизм разделения программы на модули. В концепции MVC наличие трех блоков (Model, View, Controller) прописано жестко. Соответственно каждый функциональный модуль должен состоять из трех блоков, что в свою очередь, несколько усложняет архитектуру функциональных модулей программы.
• Усложнен процесс расширения функционала. Проблема очень схожа с вышеописанной. Недостаточно просто написать функциональный модуль и подключить его в одном месте программы. Каждый функциональный модуль должен состоять из трех частей, и каждая из этих частей должна быть подключена в соответствующем блоке.

RoR, который является одним из лучших Ruby-фреймворков для веб-разработки, следует архитектурному шаблону MVC.

Схема работы архитектурного шаблона проектирования MVC представлена на рисунке 17.

Рисунок 17 - Схема работы шаблона проектирования MVC

Рассмотрим конкретный пример реализации MVC. Предположим, пользователь сайта хочет перейти к странице описания продукта. Пользователь переходит по URL products/16, браузер отправляет get-запрос. Далее переходим в контроллер Products_controller, где находится метод show. В этом методе происходит получение данных о товаре с помощью модели. Этот же метод вызывает представление, передавая данные о товаре: @product=Product.find(params[:id]);

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

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

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

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

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

Диаграмма последовательности полезна для описания алгоритма действий, но она не дает представления о поведении определенного объекта в рамках отдельного варианта использования или системы в целом, что необходимо при объектно-ориентированном программировании.

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

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

Описать поведение отдельно взятого объекта помогает диаграмма состояний.

Диаграмма состояний представлена в графическом материале. На диаграмме присутствует два объекта – «пользователь» и «интернет-магазин», и этого вполне достаточно, чтобы описать их взаимодействие. Пользователь заходит на сайт с целью просмотра и возможного заказа товаров. Отклик системы на такое поведение пользователя, если он не авторизован, - запросить ввод логина и пароля. Пользователь, чтобы получить доступ к заказу товара, обязан ввести логин (email) и пароль. Система проверит данные, и, если такой пользователь существует, она выведет страницу добавления товара в корзину. Иначе, система покажет сообщение об ошибке и предложит пользователю либо ввести данные снова.   

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