Вопрос проектирования архитектуры Java / JSF / Spring / WebFlow DDD

Question

В настоящее время я портирую массивное старое приложение Oracle Forms на JSF, и мне нужно принять решение по модели предметной области.

Я заблокирован для использования шаблонов Spring JDBC (без ORM) и использования уровня DAO для решения проблем с устаревшей схемой базы данных, которая должна была быть разработана кооперативами 1-го года.Для модели предметной области я действительно хотел бы сделать вещи в высшей степени OO, например: предположим, что существует объектный план Plan.Цель была бы слишком высокой, если бы она могла выполнять PlanInstance.load (byId ("12345")), PlanInstance.save (), .delete (), .create () и т. Д. И т. Д., Но затем возникает ситуация;поскольку эти доменные объекты содержат ссылки на bean-компоненты с состоянием (например, хранилища), они не могут быть сериализованы.Как можно преодолеть это?

Первоначально я начал разделять такие вещи, как: PlanData (Statefull, SessionScoped), который используется PlanManager (Stateless, Singleton).Таким образом, код общего контроллера извлекается и не допускается дублирование в каждом bean-объекте области сеанса, и, что наиболее важно, позволяет сериализовать bean-объекты области видимости.

На данный момент мне действительно нужно структурировать его в стиле OOсвести к минимуму сложность, но я просто не знаю, как я могу иметь объект в области видимости сеанса, когда он имеет ссылки на объекты с состоянием (из-за ошибок сериализации).

Единственная возможность, о которой я могу думать, - это сделать переходы с сохранением состояния транзитными и разработать какой-то механизм для повторного внедрения зависимостей, когда бин не сериализован.Может ли кто-нибудь дать мне какое-либо понимание путей решения этой дилеммы?Должен быть какой-то шаблон / практика, которая решает, что я, вероятно, просто упускаю.

Answer 1

Я бы держал состояние и управление этим состоянием отдельно (т.е. Plan vs PlanManager.) Используя схему доступа к данным (PlanManager), вы оставляете дверь открытой для использования ORM позже, (скажем), если схема db будет переработана. в будущем. Объединение государства и управления состояниями в одном классе (PlanInstance) противоречит ОО принципу единой ответственности.

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

Бины с состоянием определяют, когда загружать, вызывать логику, изменять состояние и сохранять объекты данных. Они предоставляют контекст для ваших доменных объектов. В некоторых проектах (часто называемых моделью анемичных доменов) доменные объекты не имеют поведения, и вся логика существует в сервисах без сохранения состояния. Если я правильно понимаю, вам нужна инкапсуляция состояния и поведения в объектах вашего домена и что объектам домена необходимо использовать сессионные компоненты с состоянием для выполнения своей работы. Там, где это возможно, старайтесь учитывать функциональность в объектах домена, чтобы не полагаться на состояние сеанса (упростит тестирование), или выталкивать эти функциональные возможности в компонент службы, который вызывается с соответствующим состоянием сеанса. Если у вас нет выбора, кроме как использовать ссылки на bean-объекты с состоянием из поведения модели вашего домена, bean-компоненты с состоянием могут предоставить необходимые ссылки на состояние / репозиторий в качестве параметров для вызовов методов ваших объектов домена. Таким образом, доменные объекты по-прежнему не сохраняют состояния, но могут реализовать доменную логику с использованием bean-компонентов с состоянием.

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