Представление данных в 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-сервера: контроллер обрабатывает запрос, инициирует реализацию бизнес-логики и передает управление представлению для формирования ответа, основанного на модели