Bea*_*ker 7 architecture transactions
我有一个3层架构,看起来大致如下:
客户 - >业务 - >数据
交易理想情况应该从哪里开始？
有一种观点认为交易应该只从数据层的顶部开始.Business层仅使用业务逻辑操作业务对象,并且从不了解事务.业务完成所有操作对象的工作,然后将它们交给数据层进行持久化.这是一种适用于较低层的RESTful哲学.
另一种想法是,交易应该从业务层的顶部开始.业务层定义了逻辑工作单元,而不是数据层,因为逻辑工作单元有时包含业务逻辑,而不仅仅是数据逻辑.
我确实喜欢尽可能降低交易问题.但我也发现,除非只是CRUD操作,否则可能需要额外的努力和设计挑战来尝试将业务逻辑保留在数据层之外.如果您使用大锤应用RESTful设计模式,则可以使应用程序具有非常少的非CRUD操作.
甚至还有第三种思想流派,即客户可以启动交易,以便在需要时可以组合多个业务运营.但现在客户正在定义工作单位？这不是一个商业问题吗？
第四个想法是说我的客户端可以只是SOA组件,可以参与即使在客户端之外启动的XA事务!
我们的开发人员希望某些标准更具体,而不仅仅是"在任何您想要的地方开始交易"
有没有人对这个问题有任何意见或建议？
谢谢!
事务是一个业务概念，它应该在业务层内进行协调。
单独操作对象通常没有什么好处，并且跨越多种类型的对象之间的操作已经是一个事务。因此，第一个思想流派是处理非常基本的案例。
当您的业务层处理事务时，谁启动事务并不重要：客户端或其他服务。此外，只有当业务层意识到长时间运行（分布式）事务时，才能支持它们。
| 归档时间： |
|
| 查看次数： |
587 次 |
| 最近记录： |