应该在哪里“@Transactional”放置服务层或DAO

首先,我可能会问一些以前曾被问及过的问题,但是我却找不到search结果。 一般来说(或总是:))我们定义了服务层上的事务性注释,通常是春季冬眠

Controller-> Manager-> Dao-> Orm。

我现在有一种情况,我需要在基于客户端站点的域模型之间进行select。 假设客户A正在使用我的域名模式,但是其他客户端网站会给我一个networking服务,而不是使用我们的域名模式。

我应该更换哪一层。 我相信它必须是Dao,它将从Web服务获取数据并将其发送回去。两个分别写入的Dao层并根据场景插入。

现在我已经意识到,当我们把@Transactional放在服务层时,我们一直在做紧耦合(如果有这样的事情或者说没有松耦合)。 这么多大脑不会是错的,或者他们(我怀疑它)。

所以问题是“哪里应该”@Transactional“放置服务层或DAO? 这是服务层向下,我应该更换。

理想情况下,服务层(经理)代表您的业务逻辑,因此它应该用@Transactional注释。

服务层可能会调用不同的DAO来执行数据库操作。 让我们假设你有一个服务方法中有3个DAO操作的情况。 如果您的第一个DAO操作失败,另外两个可能仍然通过,并且最终会导致DB状态不一致。 注释服务层可以让您免于这种情况。

你会希望你的服务是事务性的。 如果您的DAO是事务性的,并且您在每个服务中调用不同的DAO,那么您将拥有多个tx,这不是您想要的。 使服务调用成为事务性的,并且这些方法中的所有DAO调用将参与该方法的tx。

我会build议把@Transactional放在服务层方法中,因为我们可以有多个DAO实现。 通过使用我们可以使我们的服务将交易。 参考

最佳做法是使用通用BasicService来提供通用服务。

该服务是放置@Transactional的最佳位置,服务层应该为逻辑上处于事务中的用户交互保存详细级用例行为。 这样我们可以保持Web应用程序代码和业务逻辑之间的分离。

有很多CRUD应用程序没有任何重要的业务逻辑,因为他们有一个服务层,只是通过控制器和数据访问对象之间传递的东西是没有用的。 在这些情况下,我们可以把交易注释放在道。

所以在实践中你可以把它们放在任何一个地方,这取决于你。

通过在您的服务中进行多个呼叫,您需要使用@Transactional服务。 不同的服务调用将在不同的事务执行,如果你把@Transactional服务。

它是基于应用程序types的个人select,如果应用程序跨越多个模块并且大部分操作都基于@CRUD,则在服务级别具有@transactional注释会使得更多的感知。引擎types应用程序,如调度程序,作业服务器,@ etl报告应用程序,其中会话和用户的概念不存在,那么在上下文级别的传播事务是最合适的…我们不应该最终通过把@transactional每个地方结束交易反对模式来创build集群交易…反正务实的交易控制JTA2是最合适的答案…再次取决于天气,你可以在给定的情况下使用它…

你应该在服务层使用@Transactional,如果你想改变客户端B的域模型,你必须在不同的模型中提供相同的数据,你可以通过提供不同的服务来改变域模型而不影响DAO层,或者通过创build一个接口,在不同模型和相同服务的接口上实现基于客户端的模型。这个决定是基于业务需求和项目的范围。