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

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/3886909/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-08 04:09:39  来源:igfitidea点击:

Where should "@Transactional" be place Service Layer or DAO

springtransactionsdao

提问by Shahzeb

Firstly it is possible that I am asking something that has been asked and answered before but I could not get a search result back . Okay generally (or always so far:) ) We define transactional annotations on service layer typical spring hibernate crud is usually

首先,我问的问题可能是之前有人问过和回答过的,但我无法返回搜索结果。好的一般(或一直到现在:))我们在服务层上定义事务注释典型的spring hibernate crud通常是

Controller->Manager->Dao->Orm .

Controller->Manager->Dao->Orm 。

I now have a situation where I need to choose between the domain model based on client site . Say client A is using my domain model all is good but then an other client site would give me a web service and not be using our domain model .

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

Which layer should I be replacing . I believe it has to be DAO which will be getting me data from web service and sending it back.i.e two separately written DAO layers and plugged in based on scenario .

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

I have now realized that we have been doing tight coupling (if there is such a thing or say not having loose coupling) when we put @Transactionalin Service layer . So many brains can not be wrong or are they (I doubt it).

我现在意识到我们在放入@TransactionalService 层时一直在做紧耦合(如果有这种事情或者说没有松散耦合)。这么多大脑不可能是错的,或者是他们(我怀疑)。

So question is "Where should "@Transactional" be place Service Layer or DAO ?" and is it service layer downwards I should be replacing .

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

采纳答案by Badal

Ideally, Service layer (Manager) represents your business logic and hence it should be annotated with @Transactional.

理想情况下,服务层(Manager)代表您的业务逻辑,因此应该用@Transactional.

Service layer may call different DAOs to perform DB operations. Lets assume a situation where you have 3 DAO operations in a service method. If your 1st DAO operation failed, other two may be still passed and you will end up with an inconsistent DB state. Annotating Service layer can save you from such situations.

服务层可能会调用不同的 DAO 来执行 DB 操作。让我们假设在一个服务方法中有 3 个 DAO 操作的情况。如果您的第一个 DAO 操作失败,则其他两个可能仍会通过,您最终会得到不一致的 DB 状态。注释服务层可以使您免于这种情况。

回答by hvgotcodes

You are going to want your services to be transactional. If your DAOs are transactional, and you call different DAOs in each service, then you would have multiple transactions, which is not what you want. Make the service calls transactional, and all DAO calls inside those methods will participate in the transactions for the method.

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

回答by kapil das

i will suggest to put @Transactional in Service layer methods since we can have multiple DAO implementations. by using this we can made our services will be transactional. refer

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

best practice is to use A generic BasicService to offer common services.

最佳实践是使用通用的 BasicService 来提供公共服务。

The Service is the best place for putting @Transactional, service layer should hold the detail-level use case behavior for a user interaction that would logically go in a transaction. in this way we can have maintain separation between web application code and business logic.

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

There are a lot of CRUD applications that don't have any significant business logic, for them having a service layer that just passes stuff through between the controllers and data access objects is not useful. In these cases we can put transaction annotation on Dao.

有很多 CRUD 应用程序没有任何重要的业务逻辑,因为它们有一个仅在控制器和数据访问对象之间传递内容的服务层是没有用的。在这些情况下,我们可以在 Dao 上添加交易注释。

So in practice you can put them in either place, it's up to you.

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

By having multiple calls in your service you need @Transactional in service. different calls to service will execute in different transactions if you put @Transactional in service.

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

回答by David Hamas

It's of a personal choice based on application types, if application is layerd across many modules and majority of operations are @CRUD based ,then having @transactional annotation at service level makes more sence.. engine type application like schedulers , job servers,@etl report apps, where sessions and user concept does not exists, then propagational transaction at context level is most suitable... we should not end up creating clusterd transactions by putting @transactional every where ending up transactional anti patters...anyways for pragmatic transaction control JTA2 is most suitable answer...again it depends on weather you can use it in a given situations...

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

回答by Sonia Jain

You should use @Transactional at service layer, if you want to change the domain model for client B where you have to provide the same data in a different model,you can change the domain model without impacting the DAO layer by providing a different service or by creating a interface and implementing the interface in different model and with the same service populate the model based on the client.This decision is based on the business requirement and the scope of the project.

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