N 层架构中的事务边界答案

【问题标题】：Transaction boundaries in an N-tier architectureN 层架构中的事务边界
【发布时间】：2013-04-10 11:40:26
【问题描述】：

我的 3 层架构大致如下所示：

客户 -> 业务 -> 数据

理想的交易应该从哪里开始？

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

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

我确实喜欢尽可能降低交易关注度的想法。但我也发现它可能需要额外的努力和设计挑战来尝试将业务逻辑排除在数据层之外，除非它只是 CRUD 操作。如果您将 RESTful 设计模式与大锤一起应用，则可以使您的应用程序几乎没有非 CRUD 操作。

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

第 4 流派认为，我的客户端可能只是 SOA 组件，可以参与甚至在客户端外部启动的 XA 事务！！

我们的开发人员想要一些更具体的标准，而不仅仅是“随心所欲地开始交易”

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

谢谢！

【问题讨论】：

【解决方案1】：

事务是一个业务概念，应在业务层内进行协调。

孤立地操作对象通常没有什么好处，并且跨越多种类型的对象之间的操作已经是一个事务。所以第一流派是处理非常基本的案例。

当您的业务层处理交易时，谁开始交易并不重要：客户或其他服务。此外，只有在业务层知道它们时才能支持长期运行（分布式）事务。

【讨论】：

【解决方案2】：

在

客户 -> 业务 -> 数据

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

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

client1-> business1 => data1 , business1 => data2

【讨论】：

反对的论点是你可以重构做永远不需要从业务方法调用两个不同的数据方法。这假设您的业务方法本身的范围非常有限。我不完全同意这个论点，但我看到一个 RESTful 设计模式被如此热情地应用，它确实将 99% 的跨域复杂性排除在应用程序之外。它值得吗？不确定。 :)
“重构永远不需要调用两个不同的数据方法”在任何服务中都是一个非常理想的想法。在我看来，对于这种情况，围绕交易不需要太多计划。在数据层方法中，只需在方法开始处创建一个 connection.setautocommit("false") ，然后在 finally 块中将其设置回 true 或回滚。应用程序和数据库关系很少那么简单。