Myc*_*haL 5 java jpa lazy-loading
我正在开发一个体系结构Hibernate/JPA/Spring/Zk,而且我现在将这些问题成倍增加,因为我必须学习很多框架.
我有一个问题让我困惑了好几天.
我听说"模式"OpenSessionInView保持活跃的Hibernate事务来进行延迟加载.许多人还说模式不是很干净.
而另一方面,据说PersistentContext扩展不是线程安全的,因此不适合保持entityManager的存活.
那么,这些问题的真正解决方案是什么？我认为这些问题源于ajax的引入,它允许更多的可能性,特别是在必要时使用延迟加载来加载一些重的集合.
暂时,我在扩展模式下尝试了@PersistenceContext.它正在工作......我必须为我的JUnit测试设置它,以及它在我的Web应用程序中也工作,延迟加载没有更多配置.
这是框架的演变(Spring,JPA 2.0)意味着现在使用PersistentContext更容易和更"干净"吗？
如果不是这种情况,我们应该使用Spring的OpenSessionInViewFilter并在事务模式下替换PersistentContext吗？
谢谢.
我听到了。自 2008 年以来，我已经在多个应用程序中实现了这两种模式。现在，我完全放弃了任何有状态模式。当您向客户端引入状态时，您会带来可扩展性和状态管理问题：是否在客户端中合并，是否在用户会话中保存，当您执行向导并且对象在保存之前必须是瞬态时会发生什么？您将如何同步客户端和服务器端状态？当数据库发生变化时会发生什么——客户端会崩溃吗？
看看现有技术的趋势，包括Spring MVC：该模式是构建两个项目：1）restful webservices 2）用户界面。状态通过不可变的域模型共享。当然，您最终可能会维护一组 dto，但它们是可预测的、廉价的并且可以无限扩展。
我的推荐？如果您想重用服务器端验证，请避免通过网络发送代理对象并在客户端上处理 dto，或者与客户端共享域模型。可以通过 Ajax 通过细粒度 api 调用来加载惰性集合。这样，您就可以将完全控制权交给客户。
这就是社交网络在过去五年中的扩展方式。