Многоуровневая архитектураМногоуровневая архитектура сосредоточена на иерархическом распределении отдельных частей системы при помощи эффективного разделения отношений. Каждая часть соотносится с определенным уровнем (layer), для каждого уровня заданы выполняемые им функции, уровни выстроены в стековую структуру (то есть находятся один поверх другого). Например, типичная архитектура для веб-приложений включает уровень представления (компоненты пользовательского интерфейса), уровень бизнес-логики (обработка данных) и уровень доступа к данным. При этом уровень представления считается высшим, за ним идет уровень бизнес-логики, а за уровнем бизнес-логики – уровень доступа к данным. Принципы многоуровневой архитектуры: · Проектирование четко устанавливает разграничение функций между уровнями. · Нижние уровни не зависимы от верхних уровней. Это позволяет использовать компоненты одного уровня в разных приложениях. · Верхние уровни вызывают функции нижних уровней, но при этом взаимодействуют только соседние уровни иерархии. Использование многоуровневой архитектуры обеспечивает следующие преимущества: § Изоляция. Разработка и обновление ПО могут быть изолированы рамками одного уровня. § Производительность. Распределение уровней на отдельные физические компьютеры повышает производительность и отказоустойчивость. § Тестируемость. Уровни допускаю независимое тестирование. Многоуровневая архитектура активно применяется при создании бизнес-приложений и сайтов, особенно приложений масштаба предприятия. При этом используется следующий набор уровней (рис. 24). 1. Уровень представления (presentation layer) – ответственен за взаимодействие с пользователем, ввод и вывод информации. 2. Бизнес уровень или уровень бизнес-логики (business logic layer) – обрабатывает информацию, реализуя конкретные бизнес-правила. 3. Уровень доступа к данным (data access layer) – обеспечивает загрузку и сохранение информации, используя источник данных (файл, база данных) или внешний сервис. Рис. 24. Уровни бизнес-приложения. Для каждого уровня дополнительно можно выделить типичный набор компонент (рис. 25). Заметим, что не все из перечисленных компонент (и даже уровней) должны присутствовать в каждом бизнес-приложении. Рис. 25. Компоненты отдельных уровней. 1. Компоненты пользовательского интерфейса. Они предназначены для вывода информации и для ввода данных пользователем. Эти компоненты могут быть элементами Windows-интерфейса или элементами веб-интерфейса. 2. Компоненты сценариев. Как правило, система подчиняется определённым правилам взаимодействия с ней. Например, в приложении для продажи товаров реализуется следующий сценарий: пользователь выбирает категорию товара из списка категорий, система показывает список товаров, затем пользователь выбирает товар, и система показывает данные по товару. Для того чтобы упорядочить такие сценарии и повторно их использовать, они объединяются в специальные объекты. Кроме этого, создается специальный механизм, который позволяет пользователю работать с системой только по определенным сценариям. 3. Рабочие потоки (workflows). После получения данных от пользователя они должны быть использованы при выполнении бизнес-процессов (рабочих потоков). Бизнес-процессы состоят из шагов, которые должны быть выполнены в определенном порядке. Например, система должна подсчитать общую сумму заказа, проверить данные кредитной карты и организовать доставку товара. При этом заранее неизвестно, сколько времени потребуется на выполнение этих шагов. Поэтому нужен механизм управления этими операциями. 4. Бизнес-компоненты. В этих компонентах реализуются бизнес-правила и решаются основные задачи. Другими словами, в них реализуется бизнес-логика приложения. Например, в системе продажи товаров нужно реализовать способ подсчета общей стоимости покупки и назначить соответствующую плату за доставку. 5. Агенты сервисов. Когда бизнес-компоненту понадобится функциональность внешнего сервиса, то он должен обратиться к некоторому объекту, представляющему в системе сам сервис. На этих агентов часто ложится задача преобразования формата данных внешнего сервиса к формату вызывающего компонента. Например, бизнес-компоненты могут использовать одного агента сервиса для взаимодействия с сервисом проверки кредитных карт и другого агента для взаимодействия с сервисом обработки данных от курьера. 6. Интерфейсы сервисов. Чтобы сервисы могли воспользоваться функциональностью друг друга, а приложения ‑ функциональностью сервисов, должен быть определен протокол обмена данными и сообщениями между сервисами и приложениями-потребителями. Этот протокол объявляется как интерфейс сервиса. Часто эти интерфейсы называют бизнес-фасадом. 7. Компоненты, отвечающие за доступ к данным. Программам нужно где-то хранить данные и в какой-то момент выполнения бизнес-процесса к ним обращаться. Имеет смысл абстрагироваться от конкретного вида данных конкретного приложения в пользу универсальных компонентов, представляющих данные. Эти компоненты размещаются в слое доступа к данным. Например, чтобы показать данные о товаре пользователю, приложению понадобится получить данные о товаре из БД. Для этого будет задействованы слой доступа к данным и сама БД. 8. Бизнес-сущности. Приложению понадобится передавать данные между компонентами и уровнями. Например, список товаров должен быть передан из слоя доступа к данным в слой представления. Поэтому нужен способ представления в системе бизнес-сущностей из предметной области. Для этого могут использоваться готовые структуры данных или могут быть созданы специальные классы. 9. Компоненты, отвечающие за безопасность. В задачи таких компонентов входит обработка возможных ошибок в приложении, авторизация пользователей и т.д.
|
