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

时间:2010-10-08 00:32:10

标签: spring dao transactional

首先,我可能会问一些之前被问过并回答的问题,但我无法获得搜索结果。好吧一般(或者总是到目前为止:))我们在服务层定义事务注释典型的春天hibernate crud通常是

Controller-> Manager-> Dao-> Orm。

我现在有一种情况需要在基于客户端站点的域模型之间进行选择。 假设客户端A使用我的域模型一切都很好但是其他客户端站点会给我一个Web服务而不是使用我们的域模型。

我应该替换哪一层。我相信它必须是Dao,它将从Web服务获取数据并将其发送回来。即两个单独编写的Dao图层并根据场景插入。

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

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

6 个答案:

答案 0 :(得分:60)

理想情况下,服务层(Manager)代表您的业务逻辑,因此应使用@Transactional进行注释。

服务层可以调用不同的DAO来执行数据库操作。让我们假设您在服务方法中有3个DAO操作的情况。如果您的第一个DAO操作失败,其他两个可能仍然通过,您将结束不一致的DB状态。注释服务层可以帮助您避免这种情况。

答案 1 :(得分:55)

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

答案 2 :(得分:5)

我建议将@Transactional放在Service层方法中,因为我们可以有多个DAO实现。通过使用这个我们可以使我们的服务将是交易的。 refer

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

服务是放置@Transactional的最佳位置,服务层应该包含逻辑上进入事务的用户交互的详细级用例行为。通过这种方式,我们可以保持Web应用程序代码和业务逻辑之间的分离。

有很多CRUD应用程序没有任何重要的业务逻辑,因为它们具有只在控制器和数据访问对象之间传递东西的服务层是没有用的。在这些情况下,我们可以将事务注释放在Dao上。

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

通过在您的服务中进行多次调用,您需要@Transactional服务。如果你将@Transactional投入使用,不同的服务调用将在不同的交易中执行。

答案 3 :(得分:0)

基于应用程序类型的个人选择,如果应用程序跨多个模块分层并且大多数操作都是基于@CRUD的,那么在服务级别使用@transactional注释会使得更多的内容..引擎类型应用程序像调度程序,作业服务器,@ etl报告应用程序,其中会话和用户概念不存在,然后在上下文级别的传播事务是最合适的...我们不应该通过将@transactional放在每个结束事务性反模式的位置来最终创建集群事务...无论如何,务实的交易控制JTA2是最合适的答案......再次取决于您在特定情况下可以使用它的天气......

答案 4 :(得分:0)

您应该在服务层使用@Transactional,如果您想更改客户端B的域模型,您必须在不同的模型中提供相同的数据,您可以通过提供一个更改域模型而不影响DAO层不同的服务或通过创建接口并在不同的模型中实现接口,并使用相同的服务基于客户端填充模型。此决策基于业务需求和项目的范围。

答案 5 :(得分:-1)

我在编程课上听说过,dao层负责与数据库交互,而service是一组操作,可能与dao相关,因此数据库与否,这组操作在一个事务中,意思更好服务是事务性的。