ЛАБОРАТОРНАЯ РАБОТА № 24

Тема: Создание программной системы, использующей шаблон MVC.

Цель: научиться разделять проектируемую систему на составные части согласно

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

Краткий теоретический блок

При разработке систем с пользовательским интерфейсом, следуя паттерну MVC, нужно

разделять систему на три составные части. Их, в свою очередь, можно называть модулями или
компонентами. У каждой составной компоненты свое предназначение.
Model. Первая компонента/модуль — модель. Она содержит всю бизнес-логику
приложения. Полностью независима от остальных частей системы, «ничего не знает» о модулях
Вид и Контроллер. В некоторых проектах Модель – это просто слой данных (БД, XML-файл); в
других – это менеджер БД, набор объектов или просто логика приложения.
View. Вторая часть системы — вид. Данный модуль отвечает за отображение данных
пользователю. Его основное предназначение — предоставлять информацию из Модели в
удобном для восприятия пользователя формате. Основное ограничение Вида — он никак не
должен изменять модель, т.е. Вид обладает доступом «только на чтение» к данным. Примеры
представления: HTML-страница, WPF форма, Windows Form.
Controller. Третьим звеном данной цепи является контроллер, его основное
предназначение — обрабатывать действия пользователя. В нем хранится код, который отвечает
за обработку данных действий. Любое действие пользователя в системе обрабатывается в
контроллере. Именно через Контроллер пользователь вносит изменения в модель, точнее в
данные, которые хранятся в модели.
Взаимосвязь составных частей системы представлена на схеме:

Разделение сложной системы на модули согласно архитектурной идеи MVC

выполняется по следующему алгоритму.
Шаг 1. Отделить бизнес-логику приложения от пользовательского интерфейса
Ключевая идея MVC состоит в том, что любое приложение с пользовательским
интерфейсом в первом приближении можно разбить на 2 модуля: модуль, отвечающий за
реализацию бизнес-логики приложения, и пользовательский интерфейс. В первом модуле
реализуется основной функционал приложения. Данный модуль является ядром системы, в
котором реализуется модель предметной области приложения. В концепции MVC данный
модуль является моделью (Model). Во втором модуле реализуется весь пользовательский
интерфейс, включая отображение данных пользователю и логику взаимодействия пользователя с
приложением. Основная цель такого разделения — сделать так, чтобы ядро системы (Модель в
терминологии MVC) могла независимо разрабатываться и тестироваться. Архитектура
приложения после подобного разделения будет выглядеть следующим образом:

1
 Шаг 2. Используя шаблон Наблюдатель, добиться еще большей независимости
модели, а также синхронизации пользовательских интерфейсов
На этом шаге преследуется две цели:
1. Добиться еще большей независимости модели.
2. Синхронизировать пользовательские интерфейсы.
Понять, что подразумевается под синхронизацией пользовательских интерфейсов,
поможет следующий пример. Предположим, мы покупаем билет в кино через интернет и видим
количество свободных мест в кинотеатре. Одновременно с нами покупать билет в кино может
кто-то еще. Если этот кто-то купит билет раньше нас, нам бы хотелось увидеть, что количество
свободных мест на наш сеанс уменьшилось. А теперь поразмышляем о том, как это может быть
реализовано внутри программы. Предположим, у нас есть ядро системы (наша модель) и
интерфейс (веб страница, на которой мы осуществляем покупку). На сайте 2 пользователя
одновременно выбирают место. Первый пользователь купил билет. Второму пользователю
необходимо отобразить на странице эту информацию. Как это должно произойти? Если мы из
ядра системы будем обновлять интерфейс, наше ядро, наша модель, будет зависима от
интерфейса. При разработке и тестировании модели придется держать в голове различные
способы обновления интерфейса. Чтобы достичь этого, необходимо реализовать шаблон
Наблюдатель. С его помощью модель рассылает уведомления об изменениях всем подписчикам.
Интерфейс, являясь таким подписчиком, получит уведомление и обновится. Шаблон
Наблюдатель позволяет модели с одной стороны информировать интерфейс (вид и контроллер)
о том, что в ней произошли изменения, а с другой — фактически ничего о них “не знать”, и тем
самым оставаться независимой. С другой стороны, это позволит синхронизировать
пользовательские интерфейсы.
Шаг 3. Разделение интерфейса на Вид и Контроллер
Дальнейшее деление приложения на модули на более низком уровне иерархии. На этом
шаге пользовательский интерфейс (который был выделен в отдельный модуль на шаге 1)
делится на вид и контроллер. Сложно провести строгую черту между видом и контроллером.
Если говорить о том, что вид — это то, что видит пользователь, а контроллер — это механизм,
благодаря которому пользователь может взаимодействовать с системой, можно обнаружить
некоторое противоречие. Элементы управления, например, кнопки на веб-странице или
виртуальная клавиатура на экране телефона, это по сути часть контроллера. Но они так же
видны пользователю, как и любая часть вида. Здесь скорее речь идет о функциональном
разделении. Основная задача пользовательского интерфейса — обеспечить взаимодействие
пользователя с системой. Это означает, что у интерфейса всего 2 функции:
 выводить и удобно отображать пользователю информацию о системе;
 вводить данные и команды пользователя в систему (передавать их системе);
Данные функции и определяют то, как нужно делить интерфейс на модули. В итоге,
архитектура системы выглядит так:

2
 В итоге имеем приложение из трех модулей: Модель, Вид и Контроллер. Резюме:
1. Следуя принципам MVC, систему нужно разделять на модули.
2. Самым важным и независимым модулем должна быть модель.
3. Модель — ядро системы. Нужна возможность разрабатывать и тестировать ее
независимо от интерфейса.
4. Для этого на первом шаге сегрегации системы нужно разделить ее на модель и
интерфейс.
5. Далее, с помощью шаблона Наблюдатель, укрепляем модель в ее независимости и
получаем синхронизацию пользовательских интерфейсов.
6. Третьим шагом делим интерфейс на контроллер и вид.
7. Всё, что на ввод информации от пользователя в систему — это в контроллер.
8. Всё, что на вывод информации от системы к пользователю — это в вид.

Взаимосвязь Вида и Контроллера с Моделью.

Когда пользователь вводит информацию через контроллер, он тем самым вносит
изменения в модель, точнее в её данные. Когда пользователь получает информацию через
элементы интерфейса (через Вид), пользователь получает информацию о данных модели.
Как Вид и Контроллер взаимодействуют с моделью? Классы Вида не могут напрямую
использовать методы классов Модели для чтения/записи данных, иначе ни о какой
независимости Модели не может быть и речи. Модель представляет тесно связанный между
собой набор классов, к которым, ни у Вида, ни у Контроллера не должно быть доступа. Для
связи Модели с Видом и Контроллером необходимо реализовать шаблон проектирования Фасад.
Фасад модели является той самой прослойкой между Моделью и интерфейсом, через которую
Вид получает данные в удобном формате, а Контроллер изменяет данные, вызывая нужные
методы фасада. Схематично, в итоге, все выглядит следующим образом:

Преимущество использования MVC.

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

3
 Ход работы

Задание 1: Продемонстрируйте технологию разделения сложной системы на модули

согласно архитектурной идеи MVC на примере своего индивидуального задания.

Задание 2: Изучите реализацию шаблона Фасад по ссылке

https://metanit.com/sharp/patterns/4.3.php

Задание 3: Продолжите разработку действующего прототипа программного средства,

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

Контрольные вопросы

1. Поясните назначение разделения сложной системы на модули согласно

архитектурной идеи MVC, опишите этапы проектирования ПС в соответствии с данной идеей.
2. Опишите преимущества использования принципов MVC при разработке ПС.
3. Опишите назначение, особенности реализации и условия использования
шаблонов наблюдатель, фасад.