banq也学hibernate了?
难道jdon想用struts+hibernate?

Hibernate是JDBC和实体Bean之间的一个选择,虽然它在开发上与图形化CMP开发相比,节省了一些setXXX字段的编程工作量,但是Hibernate和CMP还是不同重要级别的技术。

Hibernate是替代Jdbc或连接池直接操作的技术,现在还有人津津乐道在研究JDBC 3.0的,象JDBC这样低层的技术除了Hibernate这样的产品研究者比较关注以外,对于一般应用者已经没有价值,这在研究方向上就发生了问题,在J2ee领域,后人总是不断站在前人的框架或层结构基础上的,就象使用Html已经没有必要知道Windows的图形API一样,J2EE领域现在关心的是如何软件如何最大重用,如何划分更细腻的层次,Hibernate无疑是持久层一项好的技术。

Struts+Hibernate确实很诱人,Struts将难以对象化的表现层实现了对象封装,其中ActionForm实际是VO变种,而持久层Hibernate输入输出参数都是VO,这样原来两个
很难实现对象化的层次被对象化了,确实是一个令人激动的事情,以后再有J2EE初学者,就要告诉它们,你们可以不学JDBC这些低层的技术了,直接从Hibernate和Struts
开始学吧,他们会觉得J2EE不再那么难了,可惜我们这些入道早点的“前辈”就要不断煎受取舍的痛苦了。

当然,Struts_Hibernate架构中,没有提供层次来防止很重要的业务逻辑层,因为这一般是由EJB的Sesssion Bean来完成,当然,也可以由
Web层的javaBeans来实现,如同OFbiz, Jive那样做一样,但是对象池等缓冲性能优化、事务锁机制、集群分布式技术都要自己实现,这些当然没有
由EJB容器实现的Session Bean来得干净,而CMP虽然不是一种O/R技术,但是作为由容器实现的技术和Session Bean的标准结合,因此我愿意采取
以下这样的技术:


Struts+ EJB Session Bean ---> CMP或BMP (重要数据、在有一对多关系或多对一关系时首选)
|
|--> Hibernate (替代以前的DAO技术中JDBC SQL直接读操作,当然性能要求更高,直接采取JDBC)




补充:Hibernate在Jboss下可以象在Tomcat下直接使用,只要EJB打包时,包含hibernate.cfg.xml和表单的mapping就可以了,按照Hibernate介绍的那种做法比较复杂,是作为JBoss的基础件MBean存在,不是很必要。

我觉得在Session Bean前加一Dao层会不会更好?就是

Struts+Dao+SessionBean+CMP(Hibernate)

session bean+o/r mapping这种架构我以前也用过,不过是castor jdo,没hibernate有名气!