Architecture N层体系结构中的事务边界

我有一个大致如下的三层体系结构：

客户->业务->数据

交易应该从哪里开始

一个学派认为事务应该只从数据层的顶部开始。业务层只使用业务逻辑操作业务对象，从不知道事务。业务部门完成所有操作对象的工作，然后将对象交给数据层进行持久化。这是一种应用于较低层次的有点宁静的哲学

另一个学派认为，事务应该从业务层的顶层开始。业务层定义的是逻辑工作单元，而不是数据层，因为逻辑工作单元有时包含业务逻辑，而不仅仅是数据逻辑

我确实喜欢尽可能降低交易顾虑的想法。但我也发现，要想将业务逻辑排除在数据层之外，可能需要额外的努力和设计挑战，除非它只是CRUD操作。如果使用大锤应用RESTful设计模式，则可以使应用程序具有很少的非CRUD操作

甚至还有第三个学派认为，客户可以启动交易，以便在需要时可以组合多个业务操作。但是现在客户正在定义工作单元？这不是一个商业问题吗

第四个学派认为，我的客户机可以只是SOA组件，可以参与在客户机之外启动的XA事务

我们的开发人员希望一些标准更具体，而不仅仅是“随心所欲地启动事务”

有人对这个问题有什么意见或建议吗

---

谢谢

交易是一个业务概念，应该从业务层内部进行协调

单独操作对象通常没有什么好处，跨多个对象类型的操作已经是一个事务。所以第一个学派的思想是处理真正基本的案例

当您的业务层处理事务时，谁启动事务并不重要：客户机还是其他服务。此外，只有当业务层知道长时间运行（分布式）事务时，才能支持这些事务。

中的

客户->业务->数据

在体系结构中，最好在业务层定义事务。我建议将事务定义为业务服务启动一个新事务或参与现有事务（如果已经启动）。这将处理业务服务被另一个业务服务调用的情况

如果业务层将多个数据层调用作为同一请求的一部分，则在数据层设置事务边界失败，如

client1->business1=>data1，business1=>data2

---

JavaEE使用会话bean启动事务，会话bean实际上是业务层。（但是JavaEE经常做出有利于集成的设计选择，而以牺牲解耦为代价）相反的论点是，您可以进行重构，从而不需要从业务方法中调用两个不同的数据方法。这假设您的业务方法本身的范围非常有限。我并不完全同意这个观点，但我看到一个RESTful设计模式被如此热情地应用，它确实将99%的跨域复杂性从应用程序中去除。值得吗？不确定。：）在任何服务中，“重构到不需要调用两个不同的数据方法”都是一个非常理想的想法。在我看来，在这种情况下，围绕交易不需要太多的计划。在数据层方法中，只需在方法的开头创建一个connection.setautocommit（“false”），然后在finally块中将其设置回true或rollback。应用程序和数据库关系很少如此简单。