Глава 4. Web-страница в роли приложения 183

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

4Л Резюме

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

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

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

Что касается модели, то мы сделали первые шаги по пути создания распределенного многопользовательского приложения. Разговор на эту тему будет продолжен в главе 5.

Для создания модели, представления и контроллера приходится затрачивать много усилий. Обсуждая объект Objectviewer, мы выяснили, что существуют способы, позволяющие автоматизировать взаимодействие элементов архитектуры MVC. Мы создали простую систему, способную представлять модель и позволяющую пользователю взаимодействовать с ней.

Разговор об образах разработки мы продолжим в следующей главе. В ней мы перейдем к рассмотрению взаимодействия клиента и сервера.

4.7. Ресурсы

Библиотека Behaviour, использованная в данной главе, находится по адресу http://ripcord.co.nz/behaviour/. Библиотеку х Майка Фостера можно скопировать, обратившись к серверу http://www.cross-browser.com.

Попытки реализовать автоматическую генерацию представления на основе модели были предприняты в рамках проекта Naked Objects (http://

Роль сервера Ajax-приложепия

Вэтой главе ...

•Использование существующих архитектур

вAjax-приложении

•Обмен содержимым, кодом сценариев

иданными с сервером

•Передача обновленных данных серверу

•Объединение нескольких запросов

в одном HTTP-обращении

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

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

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

Помимо рассмотрения общих вопросов, связанных с работой приложения, мы также уделим внимание деталям взаимодействия клиента и сервера. В главе 2 вы получили основные сведения об объекте XMLHttpRequest

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

ивыясним, есть ли альтернатива разбору XML-документов с применением методов DOM. В последнем разделе мы представим систему управления трафиком, связанным с обменом между клиентом и сервером в процессе работы приложения. На стороне клиента будет находиться очередь запросов, а на стороне сервера — процессы для их обработки.

Итак, рассмотрим роль сервера в Ajax-приложении.

5.1. Программы, выполняемые на сервере

В процессе работы Ajax-приложения сервер выполняет две основные функции, которые имеют существенное отличие. Прежде всего, он доставляет приложение браузеру. Мы считаем, что в процессе доставки данные не претерпевают изменения, поэтому реализуем средства, предназначенные для выполнения на стороне клиента, как набор файлов .html, .ess и . js. С передачей их клиенту справится даже самый простой сервер. Такое решение вполне жизнеспособно, но оно не единственное. Существуют альтернативные варианты. Средства, предназначенные для создания серверных программ, мы подробно обсудим в разделе 5.3.

Вторая задача сервера — это взаимодействие с клиентом, т.е. обработка запросов и подготовка ответов. Поскольку HTTP — единственный возможный в данной ситуации транспортный механизм, взаимодействие всегда должно начинаться по инициативе клиента. Сервер может только отвечать. В главе 4 мы говорили о том, что Ajax-приложение должно поддерживать модель предметной области как на стороне клиента (для обеспечения быстрого отклика), так и на стороне сервера (для доступа к ресурсам, например, к базе данных). Синхронизация этих моделей — сложная задача, и клиент без по-