首先，我可能在问一些以前已经问过并回答过的问题，但我无法得到搜索结果。我们在服务层上定义事务注解，典型的spring、hibernate、crud通常是
- Controller-〉Manager-〉Dao-〉Orm .*
我现在有一个情况，我需要在基于客户端站点的域模型之间进行选择。假设客户端A正在使用我的域模型，一切都很好，但是另一个客户端站点会给予我一个Web服务，而不是使用我们的域模型。
我应该替换哪一层。我相信它必须是DAO，它将从Web服务中获取数据并将其发送回来。即两个单独编写的DAO层，并根据场景插入。
我现在意识到，当我们把@Transactional放在服务层时，我们一直在做紧耦合（如果有这样的事情或者说没有松耦合的话）。这么多的大脑不可能是错的，或者他们是错的（我怀疑）。
所以问题是“应该把“@Transactional”放在服务层还是DAO？”，我应该替换的是服务层向下吗？
11年过去了，仍然是相关的。如果我回头看这个项目，我对领域模型的理解显然是错误的。我把ORM层视为领域模型，我们希望使用ORM和分离的实体，没有任何数据Map，没有任何DTO。这是当时的趋势。这些天域模型不是ORM和有一个适当的域模型和使用ORM或Webservices是数据源照顾这个问题。像许多人指出的是服务是正确的地方，它有适当的域模型，而不是考虑JPA（ORM）作为域模型。
7条答案
按热度按时间gxwragnw1#
理想情况下，服务层（Manager）代表您的业务逻辑，因此应该使用
@Transactional进行注解。服务层可能会调用不同的DAO来执行数据库操作。让我们假设一个服务方法中有3个DAO操作的情况。如果第一个DAO操作失败，其他两个DAO操作可能仍然会通过，最终会导致数据库状态不一致。注解服务层可以保存这种情况。
aij0ehis2#
你会希望你的服务是事务性的。如果你的DAO是事务性的，并且你在每个服务中调用不同的DAO，那么你将有多个事务，这不是你想要的。让服务调用事务性的，那些方法中的所有DAO调用都将参与该方法的事务。
whitzsjs3#
我建议把@Transactional放在服务层方法中，因为我们可以有多个DAO实现。通过使用它，我们可以使我们的服务成为事务性的。refer
最佳实践是使用通用的BasicService来提供公共服务。
服务是放置@Transactional的最佳位置，服务层应该为逻辑上进入事务的用户交互保持详细级别的用例行为。通过这种方式，我们可以保持Web应用程序代码和业务逻辑之间的分离。
有很多CRUD应用程序没有任何重要的业务逻辑，因为他们有一个服务层，只是通过控制器和数据访问对象之间的东西是没有用的。在这些情况下，我们可以把交易注解在道。
所以在实践中你可以把它们放在任何一个地方，这取决于你。
通过在服务中进行多个调用，您需要在服务中使用@Transactional。如果您将@Transactional放入服务中，则对服务的不同调用将在不同的事务中执行。
hivapdat4#
这是基于应用程序类型的个人选择，如果应用程序跨许多模块分层，并且大多数操作都是基于@CRUD的，那么在服务级别使用@transactional annotation会更有意义。引擎类型的应用程序，如调度程序，作业服务器，@etl报告应用程序，其中会话和用户概念不存在，那么在上下文级别的传播事务是最合适的...我们不应该通过把@transactional every放在结束事务反模式的地方来结束创建集群事务...无论如何，对于实用的事务控制，JTA 2是最合适的答案。。。同样，这取决于你在特定情况下可以使用它的天气。。
tnkciper5#
如果您想更改客户端B的域模型，并且必须在不同的模型中提供相同的数据，则应在服务层使用@Transactional。您可以在不影响DAO层的情况下更改域模型，方法是提供不同的服务，或者创建接口并在不同的模型中实现该接口，然后使用相同的服务填充基于客户端的模型。此决策基于业务需求和项目范围。
8ljdwjyq6#
只有当我们必须在多个数据库或表或存储库之间操作数据时，我们才应该使用@Transactional，例如，如果一个存储库无法插入数据，服务应该回滚事务，在这种情况下，我认为在服务级别添加@ Transactional是最佳实践。
但我们永远不会在Controller级别添加@Transactional！
iyfjxgzm7#
我在编程课上听说过，dao层负责与数据库交互，而服务是一组操作，这些操作可能与dao相关，因此数据库或不相关，而这组操作在一个事务中，这意味着更好的服务是事务性的。