使用Wicket + Spring + Hibernate的三层分层应用程序。你将如何处理交易？ [英] Three tier layered application using Wicket + Spring + Hibernate. How would you handle transactions?
问题描述
我正在考虑使用Spring自带的开放会话视图（OSIV）过滤器或拦截器，因为它对我来说是一个开发人员的便捷方式。如果这是你的建议，你推荐使用过滤器或拦截器，为什么？
我也想知道它将如何与 HibernateTemplate 如果我将失去将方法标记为 @Transactional（readOnly = true）等的能力，从而失去获得更细粒度事务控制的能力？
对于如何将这种解决方案与使用Hibernate和Spring的三层体系结构进行集成有一些最佳实践（因为我认为我决定使用Wicket进行演示应该没什么关系） p>
如果我使用OSIV，至少从不会遇到延迟加载异常，另一方面，我的事务在能够通过在视图中未提交进行提交之前活得更长。
这确实是个人品味的问题。
个人，我喜欢在服务层有事务边界。如果您开始思考SOA，那么每个对服务的调用都应该是独立的。如果你的视图层必须调用2个不同的服务（我们可以认为这已经是代码味道），那么这两个服务应该相互独立，可以有不同的事务配置等等。服务还有助于确保在服务之外不发生任何修改。
OTOH您将不得不更多地考虑您在服务中所做的事情（延迟加载，分组功能在相同的服务方法，如果他们需要一个共同的事务性，等等......）。
一种可以帮助减少延迟加载错误的模式是使用外部值对象的服务层。服务应始终加载所需的全部数据并将其复制到VO。你失去了持久对象和你的视图层之间的直接映射（这意味着你必须编写更多的代码），但你可能会发现你的清晰度得到了提升......
编辑：决定将基于权衡，所以我仍然认为这至少部分是个人品味的问题。服务层的交易对我来说感觉更清洁（更像SOA，逻辑明显限制在服务层，不同的呼叫显然是分开的......）。该方法的问题是LazyLoadingExceptions，它可以通过使用VO来解决。如果VO只是持久对象的副本，那么是的，这显然是DRY原则的一个突破。如果你像使用数据库视图一样使用VO，那么VO就是对你持久化对象的简化。它仍然会写更多的代码，但它会让你的设计更清晰。如果您需要插入一些授权方案，它将变得特别有用：如果某些字段仅对某些角色可见，则可以将授权置于服务级别，并且永远不会返回不应该查看的数据。
I'm thinking about using the Open Session In View (OSIV) filter or interceptor that comes with Spring, as it seems like a convenient way for me as a developer. If that's what you recommend, do you recommend using a filter or an interceptor and why?
I'm also wondering how it will mix with HibernateTemplate and if I will lose the ability to mark methods as @Transactional(readOnly = true) etc and thus lose the ability to get some more fine grained transaction control?
Is there some kind of best practice for how to integrate this kind of solution with a three tier architecture using Hibernate and Spring (as I suppose my decision to use Wicket for presentation shouldn't matter much)?
If I use OSIV I will at least never run into lazy loading exceptions, on the other hand my transaction will live longer before being able to commit by being uncommitted in the view as well.
It's really a matter of personal taste.
Personally, I like to have transaction boundaries at the service layer. If you start thinking SOA, every call to a service should be independent. If your view layer has to call 2 different services (we could argue that this is already a code smell) then those 2 services should behave independently of each other, could have different transaction configurations, etc... Having no transactions open outside of the services also helps make sure that no modification occurs outside of a service.
OTOH you will have to think a bit more about what you do in your services (lazy loading, grouping functionalities in the same service method if they need a common transactionality, etc ...).
One pattern that can help reduce lazy-loading error is to use Value Object outside of the service layer. The services should always load all the data needed and copy it to VOs. You lose the direct mapping between your persistent objects and your view layer (meaning you have to write more code), but you might find that you gain in clarity ...
Edit: The decision will be based on trade offs, so I still think it is at least partly a matter of personal taste. Transaction at the service layer feels cleaner to me (more SOA-like, the logic is clearly restrained to the service layer, different calls are clearly separated, ...). The problem with that approach is LazyLoadingExceptions, which can be resolved by using VO. If VO are just a copy of your persistent objects, then yes, it is clearly a break of the DRY principle. If you use VO like you would use a database View, then VO are a simplification of you persistent objects. It will still be more code to write, but it will make your design clearer. It becomes especially useful if you need to plug some authorization scheme : if certain fields are visible only to certain roles, you can put the authorization at the service level and never return data that should not be viewed.
这篇关于使用Wicket + Spring + Hibernate的三层分层应用程序。你将如何处理交易？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
