7

我有一个 3 层架构，大致如下所示：

客户 -> 业务 -> 数据

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

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

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

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

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

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

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

有人对这个问题有任何意见或建议吗？

谢谢！

4

2 回答 2

3

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

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

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

于 2013-04-17T16:30:38.163 回答
2

在里面

客户 -> 业务 -> 数据

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

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

客户 1-> 业务 1 => 数据 1 ，业务 1 => 数据 2

于 2013-04-17T18:00:56.033 回答