Шаблон проектирования "модель-представление-контроллер"

Thursday, April 25, 2024

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

Модель

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

Представление

Описывает то, что пользователь видит и с чем он может взаимодействовать в прикладной программе.

Контроллер

Служит в качестве посредника между моделью и представлением.

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

Класс UILabel, отвечающий за отображение для пользователя текущего счета по ходу игры, выполняет функции представления. По существу, он лишь воспроизводит информацию по отдельным пикселям и должен знать, как это делается. Обязанность знать, что именно следует воспроизводить (в данном случае — счет в игре), возлагается на другую составляющую рассматриваемого здесь шаблона.
Начинающий программист может попытаться воспользоваться счетом в игре, отображаемым средствами класса UILabel, как конкретным числом, чтобы увеличить его, прочитав его как символьную строку типа UILabel, преобразовав эту строку в число, увеличив последнее, преобразовав его обратно в символьную строку и представив ее вместо прежней строки. Однако это было бы грубым нарушением самого принципа, положенного в основу шаблона MVC. Представление, которое предоставляется пользователю, должно отражать счет в игре, но не хранить этот счет.
Счет — это данные, поддерживаемые внутренним образом, т.е. в модели. Модель может быть простой, как переменная экземпляра с открытым методом увеличения счета в игре, или же сложной, как объект класса Score с целым рядом методов специального назначения.
Счет относится к числовому типу данных, тогда как класс UILabel отображает символьную строку. Одного этого достаточно, чтобы показать, что представление и модель имеют естественные отличия.
В обязанности контроллера входит уведомление о моменте изменения счета и управление отображением обновленного счета в пользовательском интерфейсе. Это особенно очевидно, если представить, что числовое значение счета в игре требуется, так или иначе, преобразовать в форму, удобную для представления пользователю.
Допустим, что класс UILabel, представляющий счет, сообщает следующее: “Ваш текущий счет равен 20”. Предположительно, обязанность за сохранение и предоставление счета 20 пользователю возлагается на контроллер.

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

Рис. 13.2. Шаблон проектирования "модель-представление-контроллер"

Приверженность шаблону MVC особенно присуща приложениям Cocoa, поскольку этот шаблон поддерживается в самой среде Cocoa. Это видно из названий классов Cocoa. Например, класс UlView реализует представление, а класс UlViewController — контроллер, воплощающий логику управления отображением представления. В главе 11 было показано, что класс UlPickerView не содержит данные, которые он отображает. Он получает эти данные из источника данных. Следовательно, класс UlPickerView обозначает представление, а источник данных — модель.

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

Например, в одном из моих приложений загружается XML-документ из ленты новостей, а заглавия статей предоставляются пользователю в виде таблицы. Сохранение и синтаксический анализ XML-файла являются исключительно материалом модели, и поэтому они повторно используются настолько часто, что я даже не пытался писать эту часть прикладного кода, а воспользовался готовым кодом под названием FeedParser, написанным Кевином Баллардом (Kevin Ballard). Представление таблицы обеспечивается классом UITableView и также является повторно используемым как получаемое непосредственно из среды Cocoa. Однако когда класс UITableView обращается к коду моего приложения и запрашивает, что именно следует отображать в данной ячейке, или когда код моего приложения обращается к XML-документу и запрашивает заглавие статьи, соответствующее данной строке таблицы, то это уже материал, а точнее, код контроллера.

Шаблон МУС помогает найти ответы на вопросы, касающиеся тех объектов, которые должны быть видны другим объектам в приложении. Так, объект контроллера обычно должен видеть объекты модели и представления, а объекту модели или группе объектов модели обычно не требуется видеть все, что находится на пределами самой модели. Как правило, объекту представления также не требуется видеть все, что находится на пределами самого представления, но такие структурные средства, как делегирование, источник данных и пары “цель-действие”, позволяют объекту представления связываться с контроллером независимым образом.