120 Часть I. Новый взгляд на Web-приложение

вам надо обратиться к top.opener. Из-за ограниченного объема книги мы предлагаем читателям сделать это самостоятельно.)

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

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

Впроцессе обсуждения мы рассмотрели несколько шаблонов разработки.

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

иобеспечить для него дополнительную степень гибкости.

3.3. "Модель-представление-контроллер "

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

Архитектура "модель-представление-контроллер" (Model-View-Control- ler — MVC) позволяет выделить фрагменты кода, отвечающие за взаимодействие с пользователем, и отделить их от тех частей программы, которые предназначены для выполнения сложных расчетов или реализации бизнеслогики. В этой главе мы покажем, как применить ее к разработке серверных компонентов, управляющих данными для Ajax-приложения. В главе 4 мы пойдем еще дальше и применим данную архитектуру для клиентской JavaScript-программы.

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

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

Рис. 3.5. Основные компоненты архитектуры "модель—представление-контроллер". Представление и модель не могут обращаться друг к другу — они взаимодействуют только через контроллер. Контроллер рассматривается как промежуточный уровень между моделью и представлением. Благодаря такому подходу разграничиваются функции различных частей программы, обеспечивается дополнительная степень гибкости и упрощается сопровождение приложения

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

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

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

Аналогично разработчики могут модифицировать представление, не опасаясь повредить модель. Понятно, что подобная ситуация сохраняется лишь До тех пор, пока будет соблюдаться соглашение об использовании интерфей-

122 Часть i. Новый взгляд на Web-приложение

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

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

Если вам еще не знакомы базовые средства разработки Web-программ, в следующем разделе вы найдете общие сведения о них и узнаете, как повысить масштабируемость и надежность Ajax-приложения. Если вы имеете опыт работы с инструментами Web-программирования, например, с процессорами шаблонов и ORM (Object-Relational Mapping), либо с такими средствами как Struts, Spring или Tapestry, то, наверное, уже в основном владеете сведениями, которые будут излагаться здесь. В этом случае мы советуем вам сразу перейти к главе 4, в которой будут обсуждаться другие способы использования этих инструментов.

3.4. Применение МУС для серверных программ

Архитектура "модель-представление-контроллер" применима к Web-прило- жениям, даже к их классическому варианту, который мы столь интенсивно критикуем в этой книге. Сама суть Web-приложения предписывает разделение представления и модели, поскольку поддерживающие их программы выполняются на различных машинах. Значит ли это, что любое Webприложение автоматически попадает в категорию MVC и можно ли создать такую Web-программу, в которой средства представления и модели были объединены?

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

Большинство сторонников применения архитектуры "модель-представле- ние-контроллер" считают представлением не средства воспроизведения HTML-документа, а сам документ и генерирующий его код. Если применить такую точку зрения к приложению Ajax, в котором данные передаются JavaScript-клиенту, окажется, что представление — это XML-документ, передаваемый клиенту в составе HTTP-ответа. Для того чтобы отделить документ от бизнес-логики, требуются определенные навыки.

124 Часть I. Новый взгляд на Web-приложение

Генерация XML-данных для передачи клиенту

В листинге 3.5 представлен код, решающий поставленную задачу. Пока этот код далек от совершенства. В данном примере используется технология РНР совместно с базой данных MySQL, однако для нас важна лишь структура программы. Принципиально ничего не изменится, если вместо РНР мы применим ASP-, или JSP-документ, или сценарий Ruby.

Листинг 3.5. Код, генерирующий XML-данные на основе запроса к базе

<?php

//Информация для клиента о том, что ему пересылается

//XML-информация

header("Content-type: application/xml");

echo "<?xml version=\"l.0\" encoding=\"UTF-8\" ?>\n"; $db=mysql_connect("my_db_server","mysql_user") ;

//Получение данных из базы mysql_select_db("mydb",$db);

$sql="SELECT id,title,description,price,colors,sizes"

."FROM garments WHERE category=\"{$cat}\""; $result=mysql_query($sql,$db);

echo "<garments>\n";

//Просмотр набора результатов

while ($myrow = raysql_fetch_row($result)) { printf("<garment id=\"%s\" title=\"%s\">\n"

."<description>%s</description>\n<price>%s</price>\n", $myrow["id"],

$myrow["title"], $myrow["description"], $myrow["price"]);

if (!is_null($myrow["colors"])){

echo "<colors>{$myrow['colors']}</colors>\n";

}

if (!is_null($myrow["sizes"])){

echo "<sizes>{$myrow['sizes']}</sizes>\n";

}

echo "</garment>\n";

}

echo "</garments>\n"; ?>

Код РНР в листинге 3.5 генерирует XML-документ. Если условиям запроса удовлетворяют только два изделия, этот документ будет выглядеть так, как показано в листинге 3.6. Отступы были добавлены лишь для того, чтобы код стал более удобным для восприятия. Язык XML очень часто используется для обмена данными между клиентом и сервером, кроме того, в главе 2 мы уже говорили об обработке XML-документа, полученного с сервера с помощью объекта XMLHttpRequest. В главе 5 мы рассмотрим другие варианты организации обмена.

Листинг 3.6. Пример данных, сгенерированных кодом из листинга 3.5

<garments>

<garment id="SCK001" title="Golfers' Socks"> <description>Garish diamond patterned socks. Real wool.

< p r i c e > $ 7 9 . 9 9 < / p r i c e >

<sizes>S , M, L, XL, egghead</sizes> </garment>

</garments>

Итак, мы получили серверную программу Web-приложения. Считаем, что Ajax-клиент способен правильно обработать полученные XML-данные. Попробуем представить себе дальнейшее развитие этой программы. Предположим, что ассортимент продукции расширился и нам надо ввести новые категории (например, Smart, Casual, Outdoor). Кроме того, необходимо реализовать поисковую функцию и установить ссылку на сервер химчистки. Очевидно, что XML-документ позволяет включить новые данные. Однако сможем ли мы повторно использовать имеющийся код и какие препятствия встретим при решении этой задачи?

Проблемы с повторным использованием кода

Организовать повторное использование сценария в том виде, в котором он существует в данный момент, непросто. Во-первых, мы "жестко" запрограммировали SQL-запрос в составе документа. Если мы захотим изменить критерии поиска, запрос нам придется генерировать по-другому. По мере добавления вариантов запроса в программе накопится большое количество выражений. Ситуация может развиваться еще хуже. Рассмотрим следующее выражение:

$sql="SELECT id,title,description,price,colors,sizes"

."FROM garments WHERE ".$sqlWhere;

Если мы разрешим передавать произвольные выражения WHERE как CGIпараметры, то можем получить следующий результат:

garments.php?sqlWhere=CATEGORY="Menswear"

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

Во-вторых, мы "жестко" запрограммировали формат XML (он определяется структурой выражений printf и echo). Однако по ряду причин формат Данных может быть изменен. Не исключено, например, что руководство примет решение выводить не только цену, по которой продается товар, но и цену производителя.