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

首先，可能是我要问一些以前已被问到并回答过的问题，但我无法找回搜索结果。一般而言（或到目前为止）：）我们在服务层上定义事务注释，通常是Spring Hibernate Crud。

Controller-> Manager-> Dao-> Orm。

现在，我需要根据客户站点在域模型之间进行选择。假设客户端A使用我的域模型都很好，但是另一个客户端网站会给我一个Web服务而不是使用我们的域模型。

我应该替换哪一层。我认为必须是DAO，它将从Web服务获取我的数据并将其发送回去。即两个单独编写的DAO层，并根据情况插入。

我现在意识到，当我们放入@TransactionalService层时，我们一直在进行紧密的耦合（如果有这样的事情或者说没有松散的耦合）。这么多的大脑不会错，或者是（我对此表示怀疑）。

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

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

服务层可以调用不同的DAO来执行数据库操作。让我们假设一个服务方法中有3个DAO操作的情况。如果您的第一个DAO操作失败，则其他两个操作可能仍会通过，并且最终将导致数据库状态不一致。注释服务层可以使您免于此类情况。

您将要使您的服务具有事务性。如果您的DAO是事务性的，并且在每个服务中调用不同的DAO，则您将有多个事务，而这不是您想要的。使服务调用具有事务性，这些方法中的所有DAO调用都将参与该方法的事务。

我建议将@Transactional放在Service层方法中，因为我们可以有多个DAO实现。通过使用此服务，我们可以使我们的服务具有交易性。 参考

最佳实践是使用通用BasicService提供通用服务。

服务是放置@Transactional的最佳位置，服务层应保留逻辑上将在事务中进行的用户交互的详细级别用例行为。通过这种方式，我们可以保持Web应用程序代码与业务逻辑之间的分离。

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

因此在实践中，您可以将它们放在任何位置，这取决于您。

通过在服务中进行多个调用，您需要在服务中使用@Transactional。如果将@Transactional置于服务中，则对服务的不同调用将在不同的事务中执行。

这是基于应用程序类型的个人选择，如果应用程序跨多个模块分层并且大多数操作基于@CRUD，则在服务级别具有@transactional注释会更加有意义。.引擎类型的应用程序，例如调度程序，作业服务器，@ etl报告应用程序，其中不存在会话和用户概念，那么在上下文级别的传播事务是最合适的...我们不应该最终通过在每个结束事务反模式的地方放置@transactional来创建集群事务...无论如何，对于务实的事务控制JTA2是最合适的答案...同样取决于天气，您可以在给定的情况下使用它...

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