КРАТКИЙ КОНСПЕКТ книги
"Архитектура корпоративных приложений" Мартин Фаулер
- Корпоративные приложения:
- подразумевают необходимость долговременного хранения данных
- данных, как правило, бывает много
- в корпоративных приложениях множество пользователей обращаются к данным параллельно
- такая программа обычно содержит несколько сотен окон
- корпоративные приложения редко существуют в изоляции. Обычно они требуют интеграции с другими системами
- подразумевают наличие бизнес логики (с сотней частных исключений)
- Три слоя архитектуры ПО:
- Домен - Бизнес-логика приложения
- Источник данных - Обращение к базе данных, обмен сообщениями, управление транзакциями и т.д.
- Представление - Предоставление услуг, отображение данных, обработка событий пользовательского интерфейса (щелчков кнопками мыши и нажатий клавиш), обслуживание запросов HTTP, поддержка функций командной строки и API пакетного выполнения
Способы организации бизнес-логики:
Приступая к разработке корпоративного приложения важно определить, какой из трех вариантов организации логики предметной области целесообразно применить в конкретной ситуации .
1) сценарий транзакции (Transaction Script)
Процедуры, которая получает на вход информацию от слоя представления, обрабатывает ее, проводя необходимые проверки и вычисления, сохраняет в базе данных и возвращает нужные данные слою представления.
Достоинства:
- удобная процедурная модель, легко воспринимаемая всеми разработчиками;
- удачно сочетается с простыми схемами организации слоя источника данных на основе типовых решений шлюз записи данных (Row Data Gateway) и шлюз таб лицы данных (Table Data Gateway);
- определяет четкие границы транзакции.
Недостатки: если некоторым транзакциям необходимо осуществлять схожие функции, возникает опасность дублирования фрагментов кода . Можно вынести дублирующиеся фрагменты кода в отдельные методы, но в итоге приложение теряет четкую структуру
2) модель предметной области (Domain Model)
Процедуры, отвечающие за бизнес-логику размещаются в соответствующих объектах предметной области. Недостатком данной модели является сложность изучения и практического применения. Аккуратное применение модели предметной области требует навыка, а небрежность здесь просто недопустима . Второй недостаток — тесная связь модели предметной области с реляционной моделью данных и сложность отображению объектов в реляционные структуры.
3) модуль таблицы (Table Module) — это объект предметной области, работающий не с отдельным объектом, а с целым массивом данных. Модуль таблицы представляет собой промежуточный вариант, компромиссный по отношению к сценарию транзакции и модели предметной области.
Организация бизнес-логики вокруг таблиц, а не в виде прямолинейных процедур облегчает структурирование и возможность поиска и удаления повторяющихся фрагментов кода. Однако решение модуль таблицы не позволяет использовать многие технологии (скажем, наследование (inheritance), стратегии (strategies) и другие объектно-ориентированные типовые решения), которые применяются в модели предметной области для уточнения структуры логики. Применение модуля таблицы оправдано тогда, когда платформа поддерживает инфраструктуру множества записей.
Какую модель выбрать? Если логика приложения проста, модель предметной области менее соблазнительна, поскольку затраты на ее реализацию не окупаются. Но с возрастанием сложности альтернативные подходы становятся все менее приемлемыми: трудоемкость пополнения приложения новыми функциями увеличивается по экспоненциальному закону.
Один из общих подходов к реализации бизнес-логики состоит в расщеплении слоя предметной области на два самостоятельных слоя: "поверх" модели предметной области или модуля таблицы располагается слой служб (Service Layer), который действует как API приложения .
Варианты организации слоя служб:
1) использовать слой служб в виде промежуточного интерфейса, который только и делает, что направляет адресуемые ему вызовы к нижележащим объектам . Таким образом слой обеспечивает варианты использования (use cases ) приложений и предоставляет удачную возможность включить в код функции-оболочки, ответственные за управление транзакциями и проверку безопасности .
2) в рамках слоя служб представить большую часть логики в виде сценариев транзакции. Нижележащие объекты домена в этом случае могут быть тривиальными
3) "контроллер-сущность" ("controller—entity") - Главная особенность модели заключается в том, что логика, относящаяся к отдельным транзакциям или вариантам использования, располагается в соответствующих сценариях транзакции, которые в данном случае называют контроллерами (или службами)
Фаулер советует делать слой служб минимально возможным.
Источник данных
Избрав способ формирования слоя предметной области, необходимо определить, как подключить бизнес-логику к источнику данных.
Принимаемые на этом этапе решения целиком зависят от типа слоя домена :
1) Источник данных для сценария транзакции можно организовать в виде шлюза записи данных или шлюза таблицы данных.
2) Источник данных для модуля таблицы : так как основной довод в пользу использования модуля таблицы может быть связан с наличием хорошей инфраструктуры множества записей, в качестве источника данных для модуля таблицы логично использовать шлюз таблицы.
3) Источник данных для модели предметной области : слабость модели предметной области во многом обусловлена усложнением аппарата взаимодействия с базой данных, и величина проблемы пропорциональна степени сложности модели.
Если модель предметной области проста , то имеет смысл прибегнуть к решению активная запись (Active Record). Несколько ослабить зависимости поможет шлюз таблицы данных или шлюз записи данных. По мере усложнения модели стоит обратиться к преобразователю данных (Data Mapper). Этот подход отвечает требованию обеспечения максимальной независимости модели предметной области от всех других слоев системы, но сложнее всего реализуется на практике.
Слой представления
Слой представления относительно независим от выбора форм реализации нижележащих слоев системы. Первый вопрос касается того, какому типу интерфейса отдать предпочтение — толстому клиенту или HTML-обозревателю. Толстый клиент в состоянии обеспечить более привлекательную и разнообразную интерфейсную графику, но такой выбор сопряжен с дополнительными расходами по внедрению и сопровождению клиентских частей системы. В данной книге рассматриваются типовые решения из области проектирования веб-интерфейсов.
В качестве основного решения для веб-приложений Фаулер предлагает типовое решение модель—представление—контроллер (Model View Controller ). Решение во многом может быть обусловлено наличием в вашем распоряжении тех или иных инструментальных средств. Если проектируемое приложение в большей степени ориентировано на представление документов, причем в виде смеси статических и динамических Web-страниц, я рекомендовал бы контроллер страниц. Более сложные условия навигации и повышенные требования к графическому интерфейсу предполагают использование контроллера запросов.
Выбор между представлением по шаблону и представлением с преобразованием (Transform View) зависит от того, какой инструмент программирования — страницы сервера или XSLT — вы применяете. Сейчас более популярно представление по шаблону, хотя мне импонирует относительная простота тестирования, обеспечиваемая представле- нием с преобразованием. Если ваш сайт должен поддерживать возможности доступа с по- мощью разнообразных обозревателей, следует воспользоваться двухэтапным представле- нием (Two Step View).
Если
же вы вынуждены использовать несколько процессов, поверх слоя предметной области следует расположить интерфейс удаленного доступа (Remote Facade), а для взаимообмена информацией с Web-сервером — применять объекты переноса данных (Data Transfer Object).
Во второй части книги подробно описаны упоминаемые типовые решения, их принцип действия и назначение.