Компонентный подход в программировании

       

Данные–представление–обработка


Название. Данные–представление–обработка (model–view–controller, MVC).

Назначение. Интерактивные приложения с гибким интерфейсом пользователя. Требования к пользовательскому интерфейсу в интерактивных приложениях меняются чаще всего. Разные пользователи имеют разные наборы требований. В несколько меньшей степени это касается методов обработки данных, лежащих в основе таких приложений, — визуальное представление управляющих элементов может меняться вместе с интерфейсом, а сами выполняемые действия зависят от бизнес-логики и предметной области, и поэтому более устойчивы. Наименее подвержена изменениям модель данных, с которыми работает приложение.

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

Действующие силы.

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

Решение. Выделяется три набора компонентов. Первый набор — данные, модель данных или просто модель (model) — соответствует структуре данных предметной области, в которой работает приложение. Обязанности этих компонентов: представлять в системе данные и базовые операции над ними. Компоненты второго набора — представления (view) — соответствуют различным способам представления данных в пользовательском интерфейсе. Для одних и тех же данных может иметься несколько представлений. Каждому компоненту представления соответствует один компонент из третьего набора, обработчик (controller) — компонент, осуществляющий обработку действий пользователей.
Такой компонент получает команды, чаще всего — нажатия клавиш и нажатия кнопок мыши в областях, соответствующих визуальным элементам управления — кнопкам, элементам меню и пр. Эти команды он преобразует в действия над данными. В результате каждого действия требуется обновить все представления всех данных, которые подверглись

изменениям.

Структура. Основными ролями компонентов в данном стиле являются модель, представление и обработчик.

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


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

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

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


увеличить изображение
Рис. 8.2.  Сценарий обработки действия пользователя

Динамика. У системы два базовых сценария работы — инициализация всех компонентов и обработка некоторого действия пользователя с изменением данных и обновлением соответствующих им представлений и обработчиков.


увеличить изображение
Рис. 8.3.  Сценарий инициализации системы

Реализация. Основные шаги реализации следующие:

  • Отделить взаимодействие человека с системой от базовых функций самой системы. Для этого необходимо выделить структуру данных, с которыми система работает, и набор необходимых для функционирования системы операций над ними.
  • Реализовать механизм передачи изменений.


    Для этого можно воспользоваться образцом проектирования Подписчик (иначе называемым Наблюдатель, Observer).
  • Спроектировать и реализовать необходимые представления.
  • Спроектировать и реализовать необходимые обработчики действий пользователя.
  • Спроектировать и реализовать связь между обработчиком и представлением. Обычно представление должно инициализировать соответствующий обработчик. Для этого можно, например, использовать образец проектирования Метод порождения (Factory Method).
  • Реализовать построение системы из компонентов и инициализацию компонентов.


В качестве дополнительных аспектов реализации необходимо рассмотреть следующие.

  • Динамические представления, создаваемые во время работы приложения.
  • Подключаемые элементы управления, которые могут быть включены во время работы приложения. Например, переключение из режима "новичок" в режим "эксперт".
  • Инфраструктура и иерархия представлений и обработчиков.

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

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

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

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


Следствия применения образца.

Достоинства:

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


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


Недостатки:

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


Примеры. Впервые этот архитектурный стиль был использован при проектировании библиотеки разработки пользовательского интерфейса для языка Smalltalk [1]. С тех пор создатели множества подобных каркасов и библиотек используют те же принципы.

Еще один пример библиотеки для разработки пользовательского интерфейса, построенного на основе данного стиля — библиотека MFC (Microsoft Foundation Classes) от Microsoft. В ней используется более простой вариант стиля — с объединенными представлениями и обработчиками. Такая схема получила название документ-представление (Document-View): документы соответствуют моделям, представления объединяют функции представлений и обработчиков.

Такое объединение часто имеет смысл, поскольку представления и обработчики тесно связаны и практически не могут использоваться друг без друга. Их разделение на отдельные компоненты должно обосновываться серьезными причинами.

Последний пример использования этого стиля — архитектура современных Web-приложений, т.е. бизнес-приложений с пользовательским интерфейсом на основе HTML и связью между отдельными элементами, построенной на базе основных протоколов Интернет. В ней роль модели играют компоненты, реализующие бизнес-логику и хранение данных, а роль представлений и обработчиков исполняется HTML-страничками и HTML-формами, статичными или динамически генерируемыми. Далее в этом курсе построение таких приложений будет рассматриваться более детально, поэтому образец "данные–представление–обработка" имеет большое значение для дальнейшего изложения.


Содержание раздела