Приложения и уровни

Опубликовал read-php в 15.02.2011 Категория: Шаблоны корпоративных приложений PHP

Многие (если не большинство!) шаблоны в этом разделе предназначены для того, чтобы способствовать независимой работе нескольких различных уровней в приложении. Уровни корпоративной системы, подобно классам, представляют собой специализацию обязанностей, только в более крупном масштабе. Типичное разбиение системы на уровни показано на рис. ниже

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

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

Так какой же смысл разбивать систему таким образом? Как и в отношении многого другого в этой книге, ответ кроется в ослаблении связей. Поддерживая логику приложения независимой от уровня представления данных, вы делаете возможным добавление новых интерфейсов в систему без изменения либо с небольшим изменением ее кода.

Представьте себе систему управления списками событий. Конечно пользователю нужен симпатичный НТМL-интерфейс, что вполне естественно. Администраторам, поддерживающим систему, может понадобиться интерфейс командной строки для встраивания в автоматизированные системы. В то же время вы можете разрабатывать версии системы для работы с мобильными телефонами и другими портативными устройствами. Возможно, вы даже думаете о применении протоколов XML-RPC и SOAP.

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

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

Тестирование — это еще одна хорошая причина создания систем с отдельными уровнями. Общеизвестно, что веб-приложения трудно тестировать. Автоматический тест любого вида будет вынужден выполнять разбор HTML-интерфейса, с одной стороны, и работать с реальными базами данных, с другой. Это означает, что тесты должны выполняться на работоспособной системе, в результате чего существует риск повреждения самой системы, которую они призваны защищать. На любом уровне классы, которые обращаются к другим уровням, часто создают так, что они расширяют абстрактный суперкласс или реализуют некоторый интерфейс. Этот супертип может затем поддерживать полиморфизм. В контексте теста, весь уровень может быть заменен набором пустых объектов (которые часто называют «заглушками» или «фиктивными объектами»). Таким образом, вы можете протестировать логику приложения, например, с помощью фиктивного уровня данных.

Уровни полезны даже в том случае, если вы считаете, что тестирование никому не нужно и что у вашей системы всегда будет только один интерфейс. Создавая уровни с различными обязанностями, вы строите систему, составные части которой легче расширять и отлаживать. Сохраняя код, выполняющий одинаковый тип операций, в одном месте (а не разбрасывая по всему коду, например, вызовы к базе данных или методам отображения), вы тем самым снизите вероятность появления дублирования. Добавить что-то в систему относительно просто, потому что изменения будут происходить аккуратно по вертикали, а не беспорядочно по горизонтали.

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

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

Все примеры в данной главе связаны с вымышленной системой управления текстовыми списками со странным именем «Woo», которое расшифровывается как «What’s On Outside».

К участникам системы относятся различные заведения (театры, клубы, кинотеатры), места (экран 1, верхняя часть сцены) и названия мероприятия (например, фильмы Долгая страстная пятница и Как важно быть серьезным).

Операции, которые я буду описывать, включают создание заведения, добавление к нему места и вывод списка всех заведений в системе.

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

Комментариев нет

Добавить комментарий