В процессе построения модели предметной области часто допускается типичная ошибка. Уровень представления – или, в нашем случае, UI-модель – часто делается слишком близкой к модели предметной области. Если представление переходит по отношениям в предметной области, это сильно затрудняет изменение модели предметной области. Мы, как и любая группа с динамической методологией разработки, должны были сохранять максимальную гибкость. Нам никак нельзя было принимать архитектурные решения, которые привели бы к уменьшению гибкости с течением времени.
Проблема решалась при помощи паттерна «Фасад приложения», описанного Мартином Фаулером (см. раздел «Библиография» в конце главы). Фасад приложения выводит на уровень представления ограниченную часть модели предметной области. Вместо того чтобы переходить по графам объектов предметной области, уровень представления обращается к фасаду приложения с запросами на содействие в перемещении, управлении жизненным циклом, активации и т. д.
Каждая форма определяла соответствующий фасадный интерфейс. В соответствии с каноном, который гласит, что интерфейсы должны определяться потребителями (а не поставщиками), мы поместили фасадный интерфейс в пакет формы. Форма обращается к фасаду с запросом на поиск объектов предметной области и их долгосрочное сохранё – ние. В сущности, фасады управляли всеми транзакциями базы данных, так что формы вообще не знали о транзакционных границах.
Related posts: