这实际上是个人喜好问题。
就个人而言，我喜欢在服务层设置事务边界。如果您开始考虑SOA，则对服务的每个调用都应该是独立的。如果您的视图层必须调用2个不同的服务（我们可以说这已经是代码味道了），那么这2个服务应该彼此独立运行，可以具有不同的事务配置，等等。服务还有助于确保在服务之外不会进行任何修改。
OTOH，您将不得不对服务中的工作进行更多思考（延迟加载，如果需要共同的事务性，则在同一服务方法中对功能进行分组等）。
一种可以帮助减少延迟加载错误的模式是在服务层之外使用ValueObject。服务应始终加载所需的所有数据并将其复制到VO。您失去了持久对象与视图层之间的直接映射（这意味着您必须编写更多代码），但是您可能会发现自己变得清晰起来…
该决定将基于权衡取舍，因此我仍然认为，至少部分原因取决于个人喜好。服务层的事务对我来说更干净（更像SOA，逻辑明确地限制在服务层，不同的调用明显分开，…）。该方法的问题是LazyLoadingExceptions，可以使用VO来解决。如果VO只是持久性对象的副本，那么可以，这显然是对DRY原理的突破。如果像使用数据库视图一样使用VO，那么VO就是持久对象的简化。仍然需要编写更多代码，但可以使您的设计更加清晰。如果您需要插入某些授权方案，该功能将特别有用：如果某些字段仅对某些角色可见，
解决方法我正在考虑使用Spring附带的 Open View In View（OSIV）过滤器或拦截器，因为这对我作为开发人员来说似乎是一种方便的方法。如果这是您的建议，则建议使用过滤器或拦截器，为什么？
我还想知道它将如何与 HibernateTemplate 混合使用，是否会失去将方法标记为 @Transactional（readOnly =true） 等的功能，从而失去获得更多细粒度事务控制的能力？
对于如何使用Hibernate和Spring将这种解决方案与三层体系结构进行集成，是否存在某种最佳实践（因为我认为我决定使用Wicket进行演示应该没有太大关系）？
如果我使用OSIV，至少我永远不会遇到延迟加载异常，另一方面，在视图中也可以通过取消提交来使我的事务提交更长的时间。
