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

Question

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

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

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

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

Answer 1

возможно посредник - это то, что вы хотите:

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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