Hibernate延迟加载方式违背分层原则

　Hibernate支持对象间关系，如一对一，多对一等。由此，设计及编程可以真正体现面向对象的思维，如定单对象不再是只有一个商品ID，而是包括商品对象本身。
　但由此也引入了一个问题，对象加载方式。如果采用一次载入对象中所有属性的策略，有可能装入整个数据库对象，系统不能承受。所幸，Hibernate支持对象延迟加载。
　延迟加载使用CGLIB生成对象代理，使用这个对象属性时才真正去数据库读取。这样做，在小型Web网站程序中没有问题。但在分层严格的程序中，当Web层的页面及Action调用对象属性时是不允许再去访问数据库的，如此对象延迟加载也就失去了意义。
　根本来说，就是是否需要延迟加载VO对象的问题。个人认为，不应使用延迟加载。用户在调用DAO应当知道是仅需要访问定单信息，还是需要访定单中的商品信息。也就是说对象加载到什么程度，应当在方法调用时指定，而不是在使用该属性后再去数据库加载。
　对应用Hibernate而言，对象加载模式是在配置文件中定义的，不能适应VO对象加载需要。应当在调用方法中，指定对象加载模式更为恰当。当然，也可以在得到VO对象后，显式调用属性以避免Web层再延迟加载，但一是此种方法不够优雅，容易误写，二是对象加载是分次完成，效率不高。

本本主义！！

并非本本主义这么简单。J2EE 分层结构的原则是各层做各层的事情，
而很明显，访问数据库不是Web层应当完成的事情。
一个好的设计可以预先避免很多问题。

在简单的Web/Buiness/DAO在一起使用时，借助于Spring的OpenSessionInViewFilter在Web层打开Hibernate Session是可以完成程序的正常运作。但在分布式环境或有中间件环境下，如果Web层无法得到Hibernate Session,这种延迟加载方式是有问题的。退一步说，在前述简单环境下，VO对象中属性在调用时一次加载也要比分次加载效率要高。

在Hibernate3的Cirtier查询中的FetchMode.Early中已部分实现指定加载对象层次，但也只限于Cirtier模式查询。

理论上可能如此
……

如果内存1毛钱1T的话，就可以了

还是去jdon讨论数据库已死，oo重生吧

呵呵 不是本本主义是什么？

谁规定web开发设计一定要分层，还要遵守MVC模式（至于你说“分层原则”这个词我头次听说 不过明白你的意思）

我们分层、套用设计模式无非是让我们的程序更简单、易懂、容易交流、更灵活、易维护扩展......

只要本着这个原则去 写出来的程序自然就规范了（自然就分层了） 而不是说 书上说了要分层我就一定分层 什么都套个设计模式我的程序就牛B 不是

“优雅”这个词形容的很好 也有很宁静的感觉 我不是说LZ说的不对 只是我觉得那样写出来的东西会让我狂躁 别人维护起来可能会骂娘的 所以感觉这样做和讨论这个一点必要都没有

按照楼主所说提前加载本无错，关键是这就失去了延迟加载的意义，而且编程不方便

写这篇文章本意是控讨延迟加载是否必要,这是个见仁见智的话题.

架构问题并不是本本主义。如果你开发过大中型程序，应当知道多个WEB服务器和业务服务器分开布署的情形。又或者，你需要考虑系统解耦，当子系统通过Web Service访问得到VO对象后,你还能指望VO的延迟加载吗?

并且,在方法中指定对象加载方式并不复杂,且比在配置文件中lazy设置更加容易理解. 可以默认VO中所有关联对象均不加载,在调用方法指定加载对象.
方法如下:
  getHibernateTemplate().get(this.persistentClass, id);
  -->
  getHibernateTemplate().get(this.persistentClass, id, new String[]{需要加载的属性名称});
注:需要加载的属性名称应支持对象层次,如商品.用户.地址.

个人认为 web应用中在分页查看的前提下，禁用延迟加载是有必要的。openSessionInViewFilter固然可以，但session的生命周期过长。如果遇到响应时间长的页面（10秒上）更是问题。

有关系数据库，就不可能完美oo.
不要白日做梦了