为什么将@Transactional用于@Service而不是@Controller [英] Why use @Transactional with @Service instead of with @Controller

问题描述

我在堆栈溢出文章中看到了许多评论，我发现了一些与 @Transactional 一起使用 @Service 或 @Controller

通常，应该在服务层放置一个事务。

正常情况下，将在服务层级进行注释

认为交易属于服务层，它是了解工作单位和使用情况的人如果您有多个DAO注入需要在单个事务中协同工作的服务，那么这是正确的答案。 [来源]

在@service层中使用@transactional的缺点
$ b

如果我有2方法，例如saveUser（）和saveEmail（）（因为我将电子邮件存储在数据库中以便稍后发送 - 就像一个队列一样）我将在我的服务中创建一个saveUserAndSendEmail（用户用户）方法，这将是事务性的。 [来源]

这意味着我在服务层创建了许多方法，而不是像下面那样创建一个保存通用方法

  public< T> long save（T entity）throws DataAccessException {
 Session session = sessionFactory.getCurrentSession（）; 
 long getGenVal =（Long）session.save（entity）; 
 return getGenVal; 
 
 
 
 
 
根据上面的解决方案，这意味着我们有很多方法跟着LOL。 
 
 
 
 公共< T> long saveAccount（T entity）....  
 
 
 
  public< T> long saveWithAuditLog（T entity，K entity1）....  
 
 
 
  public< T> long saveWithAuditLogAndEntries（T entity，K entity，M entity）....  
 
 
 
 克服这种情况 
 
 
 
我在@Controller中使用@Transactional，只需创建一个通用保存方法并使用这种简单的保存方法保存所有实体/模型。如果有任何方法未能保存，则控制器中的所有事务成功回滚。
 
 
 
其他情况确保@Transactional应与@Controller一起使用 
 
 
 
在@Controller中：
  pt.save（entity1） ; 
 pt.save（entity2）; 
 int a = 2/0; 
 pt.save（entity3）; 
  
 如果@Transactional on Service，前2个实体成功保存但第三个不是回滚所有事务 
 
 
 
 如果@Transactional on @Controller所有事务回滚都发生异常 
 
 
 
为什么堆栈溢出问不要在控制器中执行事务，把它们放在服务层类中。 
  [来源]  
解决方案
您在询问最佳做法，最佳做法是标记 @Transactional  @Controller 不应该知道MVC逻辑中的数据持久性。
 
  @服务是基于分析生成的用例构建的，并且知道工作单元，并且还实现了对重用的思考：如果从Web上下文切换到桌面上（例如或某些其他可视化前端）其中 @Controller 图层不存在，您不会遇到任何问题，因为所有图层都封装在服务图层中。
 
 A  @Service 是合约，表示层中的修改不应要求重写 @Service 代码。
 
但是Spring不在乎你把你的位置放在哪里事务的界限，你可以把 @Controller ，但你的应用程序可能会更难以维护。
 
 
 
我希望这很清楚。对不起，对不起;英语不是我的母语。
 
I have seen many comments in stack-overflow articles I found certain things about either @Transactional use with @Service or with @Controller 

  
"Usually, one should put a transaction at the service layer."
  
  
"The normal case would be to annotate on a service layer level"
  
  
"Think transactions belong on the Service layer. It's the one that knows about units of work and use cases. It's the right answer if you have several DAOs injected into a Service that need to work together in a single transaction." [Source]
Drawback to use @transactional with @service layer

  
If I had 2 methods for example saveUser() and saveEmail() (because I store the emails in a database to send them later - like a queue) I would create in my service a method saveUserAndSendEmail(User user) which would be transactional. [Source] 
It means I create many methods in service layer instead of one Save Generic Method as follow
public <T> long save(T entity) throws DataAccessException {
    Session session = sessionFactory.getCurrentSession();
    long getGenVal=(Long) session.save(entity);
    return getGenVal;
}
According to the above solution , it means we have many methods like following LOL.. 

public <T> long saveAccount(T entity)....

public <T> long saveWithAuditLog(T entity, K entity1)....

public <T> long saveWithAuditLogAndEntries(T entity, K entity, M entity)....

OVERCOME this situation   

I USE THE @Transactional in @Controller and Just make a Generic Save Method and save all the entities/ model using this simple save method. and if any method fail to save then all the transactions in controller rollback successfully.

Other situation that ensure that @Transactional should be use with @Controller   

In @Controller:
pt.save(entity1);
pt.save(entity2);
int a = 2/0;
pt.save(entity3);
In case , @Transactional on Service, first 2 entity successfully saved but third not it not rollback all the transaction 

In case ,  @Transactional on @Controller all the transaction rollback as exception occur

why stack-overflow asked , "Don't do transactions in your controller. Put them in your service layer classes."?
[source]
解决方案
You are asking about best practice, and best practice is to mark @Transactional in the service layer because a @Controller should not be aware of data persistence in a MVC logic.

@Service is constructed on use-case generated from analysis and knows about unit of works and is also realized thinking in terms of reuse: if you switch from a web context to a desktop one (for example, or some other visual frontend) where @Controller layer doesn't exist you don't have problems because all is encapsulated in service layer.

A @Service is a contract and a modification in presentation layer should not require a rewrite of @Service code.

But Spring don't care about where you put your your transaction boundaries, you can put on @Controller but your application may will be harder to be maintained.

I hope this is clear enough. Sorry if not; English is not my native language.

                        
这篇关于为什么将@Transactional用于@Service而不是@Controller的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！