java - 为什么我们不应该创建一个 Spring MVC Controller @Transactional？

Question

关于这个话题已经有几个问题了，但根本没有任何回应真正提供论据来解释为什么我们不应该制作一个 Spring MVC Controller Transactional。见:

• Transaction not working correctly - Spring/MyBatis

• For web MVC Spring app should @Transactional go on controller or service?

• Making Spring 3 MVC controller method Transactional

• Spring MVC Controller Transactional

那么，为什么？

• 是否存在无法克服的技术问题？
• 是否存在架构问题？
• 是否存在性能/死锁/并发问题？
• 有时是否需要多个单独的交易？如果是，有哪些用例？ (我喜欢简化设计，调用服务器要么完全成功，要么完全失败。这听起来是一个非常稳定的行为)

背景:几年前，我在一个使用 C#/NHibernate/Spring.Net 实现的大型 ERP 软件的团队中工作。到服务器的往返完全是这样实现的:事务在进入任何 Controller 逻辑之前打开，并在退出 Controller 后提交或回滚。交易是在框架中管理的，因此没有人需要关心它。 这是一个绝妙的解决方案:稳定、简单，只有少数架构师需要关心事务问题，团队的其他人只是实现了功能。

在我看来，这是我见过的最好的设计。当我尝试使用 Spring MVC 重现相同的设计时，我陷入了延迟加载和事务问题的噩梦，并且每次都得到相同的答案:不要让 Controller 具有事务性，但为什么呢？

提前感谢您提供有根据的答案!

Answer 1

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

Controller 可以设为@Transactional，但实际上，通常建议只使服务层事务性(持久层也不应该事务性)。

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

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

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

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

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

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

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

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