总的来看Spring+Hibernate与JPA很相似,它们都是基于pojo的持久化。
Hibernate Session和JPA Entity Manager基本上等价,但是要记住他们的两个重要区别。
Hibernate session是一个实体缓存也是一个ORM引擎的接口。
而JPA中这两个概念是分开的。Persistence context作为缓存而entity manager则作为ORM引擎的接口。
当然还有显而易见的区别,Spring+Hibernate偏向使用XML配置映射,而JPA偏向使用Annotation,虽然两者都有XML和注释两种实现。
还有,JPA是一个标准,而Spring是对不同实现的抽象,两者的方向是不同的。JPA的方式更彻底,Java传统中都是这样的。
JPA的主要商业实现有Hibernate、Kodo、Toplink,被巨鳄们看好。
关于Cache和Transaction管理的问题,由于Spring的草根特性,为了兼容实现,它使用Tread local这种编程式的方式。而EJB 3.0则由容器自动完成这些过程。而且EJB 3.0提供了不同的persistence context范畴,可以比较方便的管理持久数据的生命周期。不过,这个观点很难说,因为如果你把Spring也看成一种容器,那么这Thread local对于你来说也是透明的,可以认为差不多。
关于EJB 3.0对生命周期的规定,让持久化的概念更清楚了,如果这些东西能够通过声明而不是编码来实现应该是惬意的,可是,问题就是很多程序员一般就喜欢自己控制,不喜欢那么透明,所以EJB一直以来兴建的这些漂亮模型总是只有少数人使用。
在事务方面,由于两者都支持生命性事务,所以程序本身看起来基本一样。区别在于配置。
Spring还是偏向XML,并且事务作为Spring对AOP应用的经典样例,transaction完全作为附加语义,可以通过配置替换各种事务实现,从JDBC、Hibernate到JTA,显然这是从编程者角度考虑的,门槛很低。
而EJB 3.0则只支持JTA,这就需要容器的支持,当然跨多资源的事务往往是企业级项目的特性,所以这种思路可以理解。而且现在也有很多开源的JTA实现了,它们完全可以让你的应用在商业EJB容器外运行。还要提一点,EJB3默认是配置上事务的,需要声明才可覆盖,这说明了EJB3对于企业应用的态度。
在JTA事务可以通过声明就以横切关注点的形势注入的时候,JTA的成本已经下降了,所以一开始就用这种API完全可行。
EJB 3.0在这方面无疑是强大的,因为本身在这方面它就是个容器规范,Java EE容器都会提供这种高级的生命周期管理,并且把生命周期作为变成模型中非常重要的一部分。所以结果就是EJB 3.0在这方面领先于Spring,声名简单,并且从实现的方式上来说,EJB 3.0在性能上和可伸缩性上有明显的优势。Spring在性能伸缩或者说分布部署的时候应该说是捉襟见肘的,Terracotta也许可以解决些,但还……