Какой шаблон подходит между фасадом и DAO?

Question

Я занимаюсь разработкой части архитектуры своих компаний для своих веб-приложений Java EE. Я довольно четко объясняю причины использования фасада и одного или нескольких DAO. Проблема у меня такова:

Будет некоторая логика, которая определенно принадлежит к уровню интеграции, потому что все дело в сохранении модели данных. Кроме того, логика выходит за рамки простого поддержания ссылочной целостности и других «сырых» задач сохранения, которые будут обрабатываться JPA и Hibernate. Я не классифицирую это как бизнес-логику, потому что он отделен от любой бизнес-функции. Однако я понимаю, что DAO должен реализовывать только логику, необходимую для доступа и сохранения объектов к источнику данных.

Я пришел к выводу, что мне нужен шаблон бизнес-объекта, который подходит для уровня интеграции. Я огляделся, и самое близкое, что я нашел (но все еще не совсем правильно), это Sun Transfer Object Assembler pattern.

Либо есть пробел в моем понимании Java EE, либо есть образец, который будет соответствовать.

Answer 1

может быть mediator, что вы хотите:

Определить объект, который инкапсулирует как набор объектов взаимодействия. Посредник способствует свободному соединению, не допуская прямого доступа объектов друг к другу, и позволяет вам независимо изменять их взаимодействие.

, то вы можете использовать DaoMediator для того, чтобы координировать два или более DAO s

Answer 2

Звучит так, как будто у вас может отсутствовать контроллер, и, следовательно, может потребоваться шаблон MVC. Контроллер будет следить за DAO и представлять согласованное представление (не думайте с точки зрения графических интерфейсов, скорее всего, с помощью интерфейса, ориентированного на клиента). Когда изменения сделаны с помощью этого представления, тогда контроллер координирует изменения модели с помощью DAO. Я подозреваю, что ваши объекты фасада могут быть видом в этом сценарии.

Сказав это, я бы не стал беспокоиться слишком много о выявлении конкретных моделей. Вы часто обнаруживаете, что, принимая во внимание все ваши требования и разделяя проблемы, где это применимо, вы в конечном итоге реализуете конкретную модель и только идентифицируете ее как таковую после этого факта.

Answer 3

Я думаю, что это шаблон DataMapper (или адаптера) между вашим DAL и вашим бизнес-слоем, но без более конкретного понимания я не мог быть уверен.

Answer 4

Рассматривали ли вы с использованием агрегатов от домена Driven Design? Я сам ученик DDD, и, похоже, бизнес-логика, которую вы пытаетесь спроектировать, может быть достигнута благодаря более богатым POJO-подобным моделям домена. У вас должен быть каждый объект домена ответственным за его совокупные объекты, а также включать любую логику в отношении этой бизнес-концепции; что ваш уровень интеграции будет координировать эти богатые объекты, но будет воздерживаться от реальной логики как таковой (т. е. нескольких условных логик).

Возможно, шаблон, который вы пытаетесь найти, на самом деле является шагом на пути к более богатым объектам домена?

Answer 5

Что обуславливает необходимость согласования между DAO? Если есть какое-то деловое предположение, которое диктует отношения.Например, у вас может быть тип счета, который, когда он «Капитал», тогда мы должны убедиться, что несколько других объектов находятся в правильном состоянии или имеют правильный набор значений. Это определенно выходит за рамки уровня данных.

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