使用 Wicket + Spring + Hibernate 的三层分层应用程序。你会如何处理交易？答案

【问题标题】：Three tier layered application using Wicket + Spring + Hibernate. How would you handle transactions?使用 Wicket + Spring + Hibernate 的三层分层应用程序。你会如何处理交易？
【发布时间】：2010-10-06 14:20:08
【问题描述】：

我正在考虑使用 Spring 附带的 Open Session In View (OSIV) 过滤器或拦截器，因为这对我作为开发人员来说似乎是一种方便的方式。如果这是您的建议，您是否建议使用过滤器或拦截器？为什么？

我也想知道它将如何与 HibernateTemplate 混合，以及我是否会失去将方法标记为 @Transactional(readOnly = true) 等的能力，从而失去获得更细粒度的事务控制的能力？

对于如何使用 Hibernate 和 Spring 将这种解决方案与三层架构集成（我认为我决定使用 Wicket 进行演示应该无关紧要），是否有某种最佳实践？

如果我使用 OSIV，我至少不会遇到延迟加载异常，另一方面，我的事务将在能够通过在视图中未提交而提交之前存活更长的时间。

【问题讨论】：

标签： java hibernate spring transactions wicket

【解决方案1】：

这真的是个人品味的问题。

就我个人而言，我喜欢在服务层设置事务边界。如果您开始考虑 SOA，那么对服务的每次调用都应该是独立的。如果您的视图层必须调用 2 个不同的服务（我们可以说这已经是代码异味），那么这 2 个服务应该彼此独立运行，可能有不同的事务配置，等等......没有事务在外部打开services 还有助于确保不会在服务之外发生任何修改。

OTOH，您将不得不更多地考虑您在服务中所做的事情（延迟加载、在同一服务方法中对需要通用事务性的功能进行分组等...）。

一种有助于减少延迟加载错误的模式是在服务层之外使用值对象。服务应始终加载所需的所有数据并将其复制到 VO。您失去了持久对象和视图层之间的直接映射（这意味着您必须编写更多代码），但您可能会发现您变得更加清晰......

编辑：这个决定将基于权衡，所以我仍然认为这至少部分是个人品味的问题。服务层的事务对我来说感觉更干净（更像 SOA，逻辑明确限制在服务层，不同的调用明确分离......）。这种方法的问题是 LazyLoadingExceptions，可以通过使用 VO 来解决。如果 VO 只是您的持久对象的副本，那么是的，这显然是对 DRY 原则的破坏。如果您像使用数据库视图一样使用 VO，那么 VO 就是对持久对象的简化。仍然需要编写更多代码，但它会让你的设计更清晰。如果您需要插入一些授权方案，这将变得特别有用：如果某些字段仅对某些角色可见，您可以将授权放在服务级别，并且永远不会返回不应查看的数据。

【讨论】：

这不仅仅是个人品味的问题，它会改变你做事的方式，从而改变性能以及代码维护和使用的容易程度。更多样板代码，更多代码可维护性令人头疼.Using VO 的声音很脏，有很多非常相似的代码，听起来有点像打破 DRY。
也就是说，VO 确实允许我对业务层中的事务进行精细控制（使用@Transactional），事务将具有更短的生命周期（更具可扩展性）和清晰的分离业务和表示层。

【解决方案2】：

如果我使用 OSIV，我至少不会遇到延迟加载异常

这不是真的，实际上它非常容易遇到臭名昭著的 LazyInitializationException，只需加载一个对象，并尝试读取它的属性，查看后，根据您的配置，您将得到 LIE

【讨论】：

投反对票没有评论？至少解释一下原因。如果发帖人说的不对，或许我们都可以从解释中吸取教训。
我也会投反对票，并附上评论。据我了解，如果您有会话并且在表示层的事务中，您将永远不会遇到延迟启动异常。并且“ after the view" 永远不会发生，因为这是最后发生的事情。我需要一个更好的解释来支持投票。
问题不在于 OSIV 本身，而是使用 OSIV 休眠，您仍然无法“自动”将先前加载的对象重新附加到新会话，对我来说，这是女巫导致的最大问题之一到谎言
您从业务层请求实体。您拥有它们并且可以访问任何属性，直到视图结束。此时您不会丢弃实体，而是以某种方式保留它（序列化它可能），然后你尝试访问一些东西并繁荣？我的 -1 ==back=to=> 0 因为它仍然不是解决方案。
如果你跨请求（例如在会话中）持久化你的 Hibernate 实体，你就会遇到一个主要的架构问题。所以是的，即使使用 OSIV 也有可能获得 LIE，但如果你这样做了，你就要求它！