通过事务将业务逻辑与数据库逻辑分开

我们的应用程序包含三层。服务层提供外部API。BO层用于我们的业务逻辑，而DAO层用于我们的数据库连接。

假设每次更新文件时，我们还希望更改文件夹中的某些内容，例如“上次修改日期”。这需要在事务中完成。要么成功，要么文件和文件夹都被编辑。否则发生故障，事务将回滚，因此两个对象都处于先前状态。

“编辑文件时编辑文件夹”操作纯粹是业务逻辑。因此，这将意味着它属于BO层。但是，我们将Objectify用于数据库，因此要启动事务，我们需要调用ofy（）。transact（...）。如果在BO层中调用此函数，则会破坏我们的设计，因为在业务层中将有数据库特定的调用（Objectify）。

什么是解决此问题的干净方法？

— 塞尔吉·亨德里克斯
source

由于交易问题而无法FileBO致电FolderBO.edit(newDate)？

— 发现

Java没有C＃TransactionScope的等效项吗？

— 伊万

在Java中，事务范围取决于您使用的框架。在JEE中，它可以由应用服务器进行管理，但通常以声明方式进行定义和管理，例如通过Spring之类的框架（通过注解，xml等）

— Laiv

不必担心尝试使应用程序的不同“层”在功能上彼此独立/互不了解。接受这样的想法：您的代码是针对其所支持的体系结构而构建的，而应侧重于使代码相对于其自身具有良好的组合。

— Ant P

Answers:

削减交易的方式确实是业务逻辑。因此，让您的DAO层为transact您提到的方法（以及可能针对commit和rollback）提供与数据库框架无关的API 。然后，您可以从BO层使用它，而不必依赖于数据库或db框架。

— 布朗博士
source

看起来Objectify是为类似原子的事务（Google Application Engine Transactions）设计的。它将要求您开发自己的事务管理抽象。

在这种情况下。抽象如何继续我如何将事务管理委托给上层？

@DocBrown方法在我看来是一种更快，更清洁的解决方案，可以实现到给定的体系结构（分层体系结构）中。

由于我们错过了太多有关该应用程序及其上下文的信息，因此Doc的解决方案在我看来也是最安全的。

但是，我建议您看一下业务层的UnitOfWork设计模式。我认为这很适合Objectify的交易管理。

简要概述一下，该模式旨在将业务规则封装到 业务事务（工作单元）中。该模式允许B.Ts之间的继承，到目前为止，我也看到了Objectify。它甚至支持合成。所以，无论是成分或继承，该方法允许复杂B.Ts。

应用于给定的体系结构，将看起来像：

FileService -> FileBO : new EditFileTransaction().execute()
                           |-> ofy().transact(...)
                           |--> FileDAO.actionA()
                           |--> FolderDAO.actionA()
                           |-> [ofy().commit(...)|ofy().rollback()]

— 莱夫
source