148 Часть II. Основные подходы к разработке приложений

Вглавах 1 и 2 мы рассмотрели основные принципы Ajax как с точки зрения практичности программы, так и с позиции используемых технологий. В главе 3 речь шла о создании кода, пригодного для сопровождения. Чтобы сформировать такой код, мы использовали реструктуризацию и образы разработки. Для простых примеров, которые приводились в книге, такие сложные действия могли показаться излишними, однако, изучив глубже принципы программирования Ajax, вы убедитесь, что данные инструменты крайне необходимы.

Вэтой и следующей главах мы подробно обсудим вопросы, относящиеся к созданию сложного масштабируемого клиента Ajax, и принципы архитектуры, следование которым позволяет выполнить эту работу. Данная глава посвящена созданию клиентского кода, соответствующего архитектуре "модель-представление-контроллер", которая была рассмотрена в главе 3. Мы также будем использовать Observer и некоторые другие образы разработки. В главе 5 речь пойдет о взаимодействии клиента и сервера.

4.1. Разновидности архитектуры МУС

В главе 3 мы рассмотрели пример реструктуризации в соответствии с принципами MVC простого приложения, предназначенного для интерактивного магазина. Большинство разработчиков считают моделью информацию на сервере и программы ее поддержки, представлением — сгенерированные данные, передаваемые клиенту, а контроллером — сервлет или набор Web-страниц, определяющих порядок работы приложения.

Однако первоначально архитектура MVC была ориентирована на программы, предназначенные для настольных систем. В Ajax-приложениях существует несколько вариантов ее применения. Рассмотрим эти варианты более подробно.

4.1.1. Применение архитектуры MVC к программам различных уровней

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

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

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

•Изображение компонента на экране (в случае пользовательского интерфейса он может быть сформирован из нескольких узлов DOM),

• Код, имеющий доступ к состоянию и позволяющий изменять изображение на экране, — это контроллер. Контроллером также являются обработчики событий (например, щелчок мышью на кнопке), но этот контроллер не имеет отношения к описанным выше представлению и модели.

Рассмотрим эти вопросы подробнее. Кнопка сама по себе демонстрирует крайне ограниченные варианты поведения. Ее состояние и внешний вид также изменяются крайне незначительно. Следовательно, применение к ней архитектуры MVC не даст практически никакого эффекта. Если мы рассмотрим более сложный компонент, например дерево или таблицу, то увидим, что он достаточно сложен для того, чтобы всерьез обсуждать вопрос использования MVC.

На рис. 4.1 условно показана архитектура MVC, применяемая к компоненту, реализующему древовидную структуру. Модель состоит из узлов дерева, каждый из которых имеет набор дочерних узлов. Для узла определены открытое и закрытое состояние. Каждый узел ссылается на некоторый бизнес-объект, представляющий файлы и каталоги. Представление состоит из пиктограмм и линий, расположенных на холсте. Контроллер поддерживает события, например, открытие и закрытие узла, отображение контекстного меню, и может инициировать обновление графического представления определенных узлов. В этом случае представление изменяет свое состояние.

Таким образом, архитектура MVC не обязательно должна быть привязана к знакомому всем сценарию Web-сервера. Обратимся к Web-браузеру.

4.1.2. Применение архитектуры MVC к объектам, присутствующим в среде браузера

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

На уровне браузера модель состоит из бизнес-объектов, представление — это страница, управляемая с помощью программы, а контроллером является сочетание всех обработчиков событий, связывающее пользовательский интерфейс с бизнес-объектами. На рис. 4.2 иллюстрируется использование MVC на этом уровне. Такой вариант применения архитектуры MVC, наверное, наиболее важен для разработчиков Ajax-приложений, так как богатое клиентское приложение Ajax естественным образом укладывается в ее рамки. Ниже мы рассмотрим данный вариант использования архитектуры "модель- представление-контроллер" и выгоды от его применения.

Если вы вспомните традиционное применение MVC для создания серверных программ (см. главу 3), то легко сделаете вывод, что в типичном Ajaxприложении можно выделить по крайней мере три уровня использования