Отделение бизнес-логики от DB-логики с транзакциями

11

архитектура

У нас есть три слоя в нашем приложении. Сервисный уровень для предоставления внешнего API. Уровень BO для нашей бизнес-логики и уровень DAO для нашего соединения с базой данных.

Допустим, каждый раз, когда мы обновляем файл, мы также хотим что-то изменить в папке, например, «дата последнего изменения». Это должно быть сделано в транзакции. Либо это успешно, и файл и папка редактируются. Или происходит сбой, и транзакция откатывается, так что оба объекта находятся в предыдущем состоянии.

Действие «Редактировать папку, когда файл редактируется» - это чисто бизнес-логика. Так что это будет означать, что он принадлежит слою BO. Однако мы используем Objectify для нашей базы данных, поэтому для запуска транзакции нам нужно вызвать ofy (). Transact (...). Если мы вызовем эту функцию на уровне BO, это нарушит наш дизайн, поскольку на нашем уровне Business будут специфические вызовы базы данных (Objectify).

Какое будет чистое решение для этой проблемы?

java design design-patterns transaction Серж Хендриккс
источник
Не можете FileBOпозвонить FolderBO.edit(newDate)из-за проблемы транзакции?
Пятнистый
java не имеет эквивалент C # TransactionScope?
Эван
В Java область транзакции зависит от используемой вами платформы. В JEE он может управляться сервером приложений, но обычно он определяется и управляется декларативно с помощью таких фреймворков, как Spring (аннотации, xml, ...)
Laiv
Не беспокойтесь о попытках сделать разные «слои» вашего приложения функционально независимыми / неосведомленными друг о друге. Примите идею, что ваш код построен для архитектуры, которую он поддерживает, и вместо этого сосредоточьтесь на том, чтобы сделать этот код хорошо составленным по отношению к самому себе.
Муравей P

Ответы:

5

То, как вы сокращаете свои транзакции, действительно является бизнес-логикой. Итак, позвольте вашему уровню DAO предоставить независимый от db framework API для transactметода, который вы упомянули (и, вероятно, для таких вещей, как commitи rollback). Затем вы можете использовать его со своего уровня BO, не делая его зависимым от вашей базы данных или вашей базы данных.

Док Браун
источник
4

Похоже, что Objectify разработан для атомарных транзакций ( Google Application Engine Transactions ). Это потребует от вас разработки собственной абстракции Управления транзакциями .

В таком случае. абстракция продолжается Как мне делегировать управление транзакциями верхним уровням?

@DocBrown подход выглядит для меня быстрее и чище решения реализовать в к данной архитектуре ( многоуровневая архитектура ).

Из-за того, что мы пропускаем слишком много информации о приложении и его контексте, решение Doc также кажется мне наиболее безопасным.

Однако я бы посоветовал взглянуть на шаблон проектирования UnitOfWork для бизнес-уровня . Я думаю, что это подходит для управления транзакциями, заданного Objectify .

Вкратце, шаблон призван инкапсулировать бизнес-правила в бизнес-операции (единицы работы). Шаблон допускает наследование между Б.Ц. и, насколько я вижу, Objectify тоже. Он даже поддерживает композицию. Так либо по составу или наследования, подход позволяет сложные B.Ts .

Применительно к данной архитектуре, будет выглядеть так:

FileService -> FileBO : new EditFileTransaction().execute()
                           |-> ofy().transact(...)
                           |--> FileDAO.actionA()
                           |--> FolderDAO.actionA()
                           |-> [ofy().commit(...)|ofy().rollback()]
LAIV
источник