Глава 4 Представление данных в Web

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

Разработка Web-приложения начинается с настройки программного обеспечения Web-сервера, что обычно сводится к созданию некоторого файла настроек, определяю­щего, какие адреса URL (Uniform Resource Locators— URLs) обслуживаются теми или иными программами. Нередко сервер способен управлять множеством программ, кото­рое можно динамически пополнять, размещая программы в подходящих каталогах. Функции Web-сервера состоят в интерпретации адреса URL запроса и передаче управле­ния соответствующей программе. Существует две основные формы представления про­граммы Web-сервера — сценарий (script) и страница сервера (serverpage).

Сценарий состоит из функций или методов, предназначенных для обработки запросов HTTP. Типичными примерами могут служить сценарии CGI и сервлеты Java. Подобная программа способна выполнять практически все то же, что и традиционное приложение. Сценарий часто разбивается на подпрограммы и пользуется сторонними службами. Он по­лучает данные с Web-страницы, проверяя строковый объект HTTP-запроса и вычленяя из него регулярные выражения; простота реализации подобных функций с помощью языка Perl снискали последнему славу одного из наиболее адекватных средств разработки сцена­риев CGI. В иных случаях, например при использовании сервлетов Java, программист по­лучает доступ к информации запроса через интерфейс ключевых слов, что нередко значительно удобнее. Результатом работы Web-сервера служит другая — ответная — строка, образуемая сценарием с привлечением обычных функций поточного вывода.

Задача формирования кода HTML посредством команд поточного вывода не очень привлекательна для программистов, а непрограммистам она вообще не по силам, хотя они с удовольствием взялись бы за Web-дизайн с помощью других инструментов. Это ес­тественным образом подводит к модели страниц сервера, где функции программы сво­дятся к возврату порции текстовых данных. Страница содержит текст HTML с "вкрап­лениями" исполняемого кода. Подобный подход, реализуемый, например, в PHP, ASP и JSP, особенно удобен, если требуется незначительная дополнительная обработка текста с учетом реакции пользователя.

Поскольку модель сценариев лучше подходит для интерпретации запросов, а схема страниц сервера — для форматирования ответов, вполне разумно применять их совмест­но. На самом деле это довольно старая идея, впервые реализованная в пользовательских интерфейсах на основе типового решения модель-представление-контроллер (Model View Controller), пример которого представлен на рис. 4.1.

Решение находит широкое применение, но зачастую трактуется неверно (это особен­но характерно для приложений, написанных до появления Web). Основная причина со­стоит в неоднозначном толковании термина "контроллер". Он употребляется во многих контекстах, и ему придается самый разный смысл, иногда совершенно противоречащий тому, который заключен в решении модель-представление-контроллер. Вот почему, го­воря об этом решении, я предпочитаю использовать словосочетание входной контроллер (input controller).

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

Основной довод в пользу применения решения модель-представление-контроллер со­стоит в том, что оно предусматривает полное отмежевание модели от Web-представления. Это упрощает возможности модификации существующих и добавления новых представ­лений. А размещение логики в отдельных объектах сценария транзакции (Transaction Script) и модели предметной области (Domain Model) облегчает их тестирование. Это особенно важно, когда в качестве представления используется страница сервера.

Здесь наступает черед практического применения второго варианта толкования термина "контроллер". Во многих версиях пользовательского интерфейса объекты представления отделяются от объектов домена промежуточным слоем объектов контроллера приложения (Application Controller), назначением которого является управление потоком функций приложения и выбор порядка демонстрации интерфейсных экранов. Контроллер приложе­ния выглядит как часть слоя представления либо как самостоятельная "прослойка" между уровнями представления и предметной области. Контроллеры приложения могут быть реа­лизованы независимо от какого бы то ни было частного представления, и тогда их удает­ся использовать повторно для различных представлений. Такая схема приемлема в слу­чаях, когда различные представления снабжены одинаковой логикой и инструментами навигации, но особенно хороша, если представления обладают разной логикой.

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

Рис. 4.1. Укрупненная диаграмма последовательностей, иллюстрирующая взаимодействие модели, представления и входного контроллера в структуре Web-сервера: контроллер обрабатывает запрос, инициирует реализацию бизнес-логики и передает управление представлению для формирования ответа, основанного на модели