为什么我们不应该创建一个 Spring MVC 控制器@Transactional？

TLDR：这是因为只有应用程序中的服务层具有识别数据库/业务事务范围所需的逻辑。设计的控制器和持久层不能/不应该知道事务的范围。

可以将控制器设为 @Transactional，但实际上通常建议只使服务层具有事务性（持久层也不应该是事务性的）。

这样做的原因不是技术可行性，而是关注点分离。控制器的职责是获取参数请求，然后调用一个或多个服务方法并将结果组合成响应，然后发送回客户端。

因此控制器具有协调请求执行的功能，并将域数据转换为客户端可以使用的格式，例如 DTO。

业务逻辑位于服务层，持久层只是从数据库中来回检索/存储数据。

数据库事务的范围实际上是一个业务概念，也是一个技术概念：在一个帐户转移中，只有在另一个帐户被贷记时才能借记，所以只有包含业务逻辑的服务层才能真正知道银行账户转账交易的范围。

持久层无法知道它在哪个事务中，例如方法 customerDao.saveAddress。它是否应该始终在自己的单独事务中运行？没有办法知道，这取决于调用它的业务逻辑。有时它应该在单独的事务上运行，有时只在 saveCustomer 也工作时才保存它的数据，等等。

这同样适用于控制器：saveCustomer 和 saveErrorMessages 是否应该进入同一个事务？您可能想要保存客户，如果失败，则尝试保存一些错误消息并向客户端返回正确的错误消息，而不是回滚所有内容，包括您想要保存在数据库中的错误消息。

在非事务控制器中，从服务层返回的方法返回分离的实体，因为会话已关闭。这很正常，解决方案是使用OpenSessionInView或执行急切获取控制器知道它需要的结果的查询。

话虽如此，让控制者进行交易并不是犯罪，但这并不是最常用的做法。

我在实践中看到了这两种情况，在大中型商业 Web 应用程序中，使用各种 Web 框架（JSP/Struts 1.x、GWT、JSF 2、Java EE 和 Spring）。

根据我的经验，最好在最高级别划分事务，即在“控制器”级别。

在一种情况下，我们有一个扩展 Struts 的 Action 类的 BaseAction 类，具有处理 Hibernate 会话管理（保存到 ThreadLocal 对象中）、事务开始/提交/回滚的 execute(...) 方法的实现，以及将异常映射到用户友好的错误消息。如果任何异常传播到此级别，或者如果它被标记为仅回滚，则此方法将简单地回滚当前事务；否则，它将提交事务。这在每种情况下都有效，通常在整个 HTTP 请求/响应周期中只有一个数据库事务。需要多个事务的罕见情况将在特定于用例的代码中处理。

在 GWT-RPC 的情况下，一个类似的解决方案是由一个基本的 GWT Servlet 实现实现的。

对于 JSF 2，到目前为止，我只使用了服务级别划分（使用自动具有“必需”事务传播的 EJB 会话 bean）。与在 JSF 支持 bean 级别划分事务相比，这里有一些缺点。基本上，问题在于，在许多情况下，JSF 控制器需要进行多次服务调用，每一次都访问应用程序数据库。对于服务级事务，这意味着几个单独的事务（全部提交，除非发生异常），这会增加数据库服务器的负担。不过，这不仅仅是性能上的劣势。单个请求/响应有多个事务也可能导致细微的错误（我不记得细节了，只是确实发生了这样的问题）。

这个问题的其他答案是关于“识别数据库/业务事务范围所需的逻辑”。这个论点对我来说没有意义，因为通常情况下根本没有与事务分界相关的逻辑。控制器类和服务类都不需要真正“了解”事务。在绝大多数情况下，在 Web 应用程序中，每个业务操作都发生在 HTTP 请求/响应对内，事务的范围是从收到请求到响应完成的所有单个操作。

有时，业务服务或控制器可能需要以特定方式处理异常，然后可能将当前事务标记为仅回滚。在 Java EE (JTA) 中，这是通过调用 UserTransaction#setRollbackOnly() 来完成的。 UserTransaction 对象可以注入到 @Resource 字段中，或以编程方式从某些 ThreadLocal 中获取。在 Spring 中，@Transactional 注释允许为某些异常类型指定回滚，或者代码可以获得线程本地 TransactionStatus 并调用 setRollbackOnly()。

因此，根据我的观点和经验，使控制器具有事务性是更好的方法。

有时你想在抛出异常时回滚事务，但同时你想处理异常在控制器中创建一个适当的响应。

如果您将 @Transactional 放在控制器方法上，这是强制回滚的唯一方法，它会从控制器方法中抛出事务，但是您无法返回正常的响应对象。

@Service
public class UserService {

    @Transactional
    public User createUser(Dto userDetails) {

        // 1. create user and persist to DB

        // 2. submit a confirmation mail
        //    -> might cause exception if mail server has an error

        // return the user
    }
}

@Controller
public class UserController {

    @RequestMapping
    public UserResultDto createUser (UserDto userDto) {

        UserResultDto result = new UserResultDto();

        try {

            User user = userService.createUser(userDto);

            // built result from user

        } catch (Exception e) {
            // transaction has already been rolled back.

            result.message = "User could not be created " + 
                             "because mail server caused error";
        }

        return result;
    }
}