Мартин Фаулер «Архитектура корпоративных программных приложений» Подготовила Ст. ПС-41 Лукиных Н. А. Глава 1. «Расслоение системы» Система как «слоеный пирог»: слой более высокого уровня пользуется службами, предоставляемыми нижележащим слоем, но тот «не осведомлен» о наличии соседнего верхнего слоя. А каждый промежуточный слой «скрывает» нижний слой от верхнего Достоинства: ◦ ◦ ◦ ◦ ◦ Отдельный слой – как целое, единое содержимое. Можно выбирать альтернативную реализацию базовых слоев Зависимость между слоями можно свести к минимуму Каждый слой стандартизирован Созданный слой может служить основой нескольким слоям более высокого уровня Недостатки: ◦ Слои способны инкапсулировать многое, но не все: модификация одного слоя связана с необходимостью внесения в другие слои ◦ Наличие избыточных слоев снижает производительность системы. Три основных слоя Представление – представление услуг, отображение данных, обработка событий пользовательского интерфейса, обслуживание запросов HTTP, поддержка функций командной строки, АPI пакетного выполнения Домен – бизнес-логика приложения Источник данных – обращение к БД, обмен сообщениями, управление транзакциями и т.д. Глава 2. Организация бизнеслогики Три типовых решения: ◦ Сценарий транзакции (Transaction Script) ◦ Модель предметной области (Domain Model) ◦ Модуль таблицы (Table Module) Сценарий транзакции - процедура, которая получает на вход информацию от верхнего слоя представления, обрабатывает ее, проводя необходимые проверки и вычисления, сохраняет в БД и активизирует операции других систем. Преимущества: ◦ Удобная процедурная модель, которая легко воспринимается разработчиками ◦ Удачно сочетается с простыми схемами организации слоя источника данных на основе типовых решений «шлюз записи данных» и «шлюз таблицы данных» ◦ Определяет четкие границы транзакции Недостатки: ◦ Возможно дублирование кода ◦ Сложная логика Модель предметной области - каждый объект наделяется только теми функциями, которые отвечают его природе. Свойства: ◦ Возможно упрощение бизнес-логики ◦ Чем сложнее модель и слой источника данных, тем дороже Модуль таблицы Модуль таблицы является единственным объектом. Обычно применяется совместно с типовым решением «множество записей». Преимущества: ◦ Возможно выполнения запроса ◦ Манипулирование его результатом в контексте модуля таблицы ◦ Передача данных графическому интерфейсу для отображения Глава 3. Объектные модели и реляционные базы данных Типовое решение «шлюз» Создание экземпляра шлюза для каждой записи, возвращаемой в результате обработки запроса к базе данных. Модель множества записей – имитирует табличную форму представления содержимого БД. Типовые решения для модели предметной области Решение «активная запись» = шлюз записи данных + бизнес-логика (особенно при повторении фрагментов кода в сценариях транзакции) Решение с «преобразователем данных» – обслуживает все операции загрузки и сохранения информации, инициируемые бизнес-логикой, позволяет независимо использовать как модель предметной области, так и схему БД Функциональные проблемы как обеспечить загрузку различных объектов и сохранение в БД ? Активная запись (Active Record): объект снабжается соответствующими методами загрузки ( load) и сохранения (save) Единица работы (Unit of Work) – позволяет отследить, какие объекты считываются, а какие – модифицируются, и обслужить операции обновления содержимого БД. Модель предметной области (Domain Model) – связанные объекты загружаются совместно таким образом, что операция считывания одного объекта инициирует загрузку другого Загрузка по требованию (Lazy Load) – предполагает использование специальных меток вместо ссылок на реальные объекты. Другие вопросы: Считывание данных Взаимное отображение объектов и реляционных структур – обеспечение взаимно однозначного соответствия между объектами в памяти и табличными структурами БД на диске Реализация отображения Использование метаданных Соединение с базой данных Глава 4. Представление данных в Web Разработка Web-приложения начинается с настройки программного обеспечения Web-сервера. Функции Web-сервера состоят в интерпретации адреса URL запроса и передаче управления соответствующей программе. Формы представления программы Web-сервера: сценарий (scrypt) и страница сервера (serverpage) Модель-Представление-Контроллер Контроллер приложения Промежуточный слой между объектами представления и объектами доменов. Назначение: управление потоком функций приложения и выбор порядка демонстрации интерфейсных экранов тест на целесообразность использования: если потоком функций системы управляет машина – ответ положительный, если пользователь – отрицательный. Типовые решения представления Представление с преобразованием Представление по шаблону Двухэтапное представление: ◦ Формируется логический экран ◦ Трансформируется в код HTML Типовые решения контроллеров Контроллер страниц – наиболее общий подход состоит в создании объекта входного контроллера для каждой страницы web-сайта. Контроллер запросов предусматривает использование единственного объекта , предназначенного для обработки всех запросов. Типовые решения контроллеров Контроллер страниц – наиболее общий подход состоит в создании объекта входного контроллера для каждой страницы web-сайта. Контроллер запросов предусматривает использование единственного объекта , предназначенного для обработки всех запросов.