当前页面: 开发资料首页 → J2EE 专题 → POJO应用框架：Spring与EJB3.0的比较
POJO应用框架：Spring与EJB3.0的比较
摘要: Spring框架虽然很流行但并不是一个标准的开源框架。EJB3.0是由Java Community Process (JCP)制订的标准框架.这两个框架结构都有一个共同核心设计理念：将中间件服务传递给耦合松散的POJOS (Plain Old Java Objects, 简单洁净Java对象)。 本文将对Srping和EJB3.0框架背后的关键不同处进行考察，并讨论其优缺点。本文的观点也适用于其它更少为人知的框架，因为他们都是对“耦合松散的POJO”的设计
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
英文原文地址:
http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html
中文地址:
http://www.matrix.org.cn/resource/article/43/43718_Spring_EJB.html
关键词： Spring EJB
艾伯特.爱因斯坦曾经说过：“一切都应该尽可能地简单，但是不能更简单。”确实如此，简化一门理论的基本假设，使我们可以专注于真正关键的地方，这正是一直以来对科学真理的追求。企业软件开发同样如此。
提供一个将复杂的事物（例如，事务、安全或持久性）对开发者进行隐藏的应用框架是简化企业软件开发的关键。一个设计良好的框架可以提高代码重用率、开发者的生产力及软件的质量。然而，现有J2EE1.4的EJB2.1框架被普遍认为设计差，且过于复杂。不满于EJB2.1的框架结构，Java开发者尝试了各种各样的中间件服务传递方法。最引人注目的是，以下两个框架引起了开发者极大兴趣并得到了大量正面的反馈。他们以未来企业Java应用所选框架的姿态展现。
Spring框架虽然很流行但并不是一个标准的开源框架。它主要由Interface21 Inc开发和控制。Spring框架结构是基于依赖注入(Dependency Injection (DI))的设计模式。它可以独立或在现有的应用服务器上运行，而且大量地使用了xml配置文件
EJB3.0是由Java Community Process (JCP)制订的标准框架，为所有主要的J2EE厂商支持。JBoss已经提供了试用版EJB3.0标准的开源或商业性质实现。EJB3.0充分利用了Java的注释
这两个框架结构都有一个共同核心设计理念：将中间件服务传递给耦合松散的POJOS (Plain Old Java Objects, 简单洁净Java对象)。 这样的框架利用截取执行上下文或在运行时将服务对象注入POJO来把应用服务“缠绕”到POJO。POJO本身并不关心这种“缠绕”，对这种框架结构也没有什么依赖。因此，开发者可专注于业务逻辑和脱离框架的POJO单元测试。除此之外， 由于POJO并不须要继承框架的类或实现其接口，开发者能够极其灵活地搭建继承结构和建造应用。
然而，在拥有同一理念的同时，两个框架结构使用不同的方式来传递POJO服务。许多书籍或文章都将Spring 或EJB3.0和EJB2.1做了比较，但是对Spring 和EJB3.0的比较并没有仔细研究过。在本文中，我将对Srping和EJB3.0框架背后的关键不同处进行考察，并讨论其优缺点。本文的观点也适用于其它更少为人知的框架，因为他们都是对“耦合松散的POJO”的设计。希望这篇文章可以帮助你选择适合你需求的最好框架。
厂商无关性
开发者选择Java平台其中最引人注目的理由之一：厂商无关性。EJB3.0正是一套设计为厂商无关的开放性标准。EJB3.0标准为所有企业Java社团里开源或商业性质厂商所开发和支持。它将开发者与应用服务器实现完全隔离。例如，JBoss的 EJB3.0实现基于Hibernate，Oracle的基于TopLink，但是开发者并不须要学习Hibernate- 或TopLink的具体API来使应用可在Jboss或Oracle上运行。厂商无关性使EJB3.0与现今其它POJO中间件框架区别开来。
但是，正如许多EJB3.0评论家迅速所指出的，在本文撰写时EJB3.0标准还没有到达一个最终版本。大概还有一到两年的时间EJB3.0才能广泛地为所有主要J2EE厂商所支持。即使你的应用服务器本身不支持EJB3.0，你仍然可以通过下载安装”内嵌的”EJB3.0产品来运行EJB3.0的应用。例如，JBoss的内嵌EjB3.0是开源产品且可以在任何J2SE5.0兼容的环境运行(例如, 在任何Java服务器上)，此产品正处于软件测试阶段。其它厂商不久也将发布自己的内嵌EJB3.0产品，特别是针对标准中关于数据持久性的部分。
另一方面，Spring一直以来都是非标准的技术，在未来可预知的一段时间内这种情况将持续下去。虽然你可以在任何应用服务器上使用Spring框架，Spring应用会被锁入在Spring本身和你选择整合进Spring的具体服务中。
Spring框架是一个开源项目，但同时它有一个XML格式的配置文件和编程接口。当然任何一个非标准的产品都会有这种“锁入”(lock-in)的情况，并不是Spring特有的。但Spring应用的长期生存能力仍然还得托Spring这个项目的福（或者是Interface21公司，它雇佣了大部分Spring核心开发人员）。除此之外，假如你用到任何一个具体的Spring服务，例如，Spring事务管理器或则Spring MVC，你也会被锁入到这些API里。
Spring的应用对终端用户是不可知的。例如，对数据持久服务，Spring框架兼容不同的DAO和JDBC的模版帮助类，如Hibernate, iBatis, 和 JDO。所以假如你需要为spring应用切换在数据持久化服务（例如从JBDC到Hibernate），你需要修改你的代码以适合新的模版帮助类。
服务整合
从一个很高的角度上看，Spring框架处于应用服务器和服务库的上方。服务整合的代码（如，数据访问模板和帮助类）属于框架，并暴露于应用开发者。相反，EJB3.0框架与应用服务器高度整合，服务整合代码也包装在一个标准接口后面。
因此，实现EJB3.0的厂商可以大大地优化整体性能和提升开发者的体验。例如，在JBoss EJB3.0的实现中，当你在用EntityManager持久化一个Entity Bean时，后台的Hibernate会话事务已经自动地帮定到调用方法的JTA 的事务上，在JTA 事务提交的同时Hibernate会话事务也提交了。你甚至可以使用一个简单的 @PersistenceContext 注释（稍候例子演示）将EntityManager和它后台的Hibernate事务绑定到一个stateful session bean的应用事务中。在一个会话中应用事务横跨多个线程，这在事务性网页应用很有用，例如，多页面的购物车。
由于高度整合的EJB3.0的框架，使简单、集成的编程接口成为可能。Oracle EJB3.0框架和其后台的Toplink持久化服务也同样程度地整合。
另一个EJB3.0整合服务的绝好例子就是集群支持。假如你在一个服务器集群上部署了一个EJB3.0的应用，所有容错(fail-over)、负载均衡、分布式缓冲和状态复制都已经自动为应用所获得可用。后台的集群支持被隐藏在EJB3.0的框架后面，对EJB3.0开发者来说这些都是完全透明不可见的。
在Spring里，很难优化框架和服务之间的通讯。例如，为了使用Spring里的声明事务服务来管理Hibernate事务，你必须显示地在XML文件中配置Spring TransactionManager和Hibernate SessionFactory对象。Spring必须电显示地管理横跨多个HTTP请求的事务。除此之外，没有别的方法均衡Spring应用里的集群。
服务组合的弹性
由于Spring的服务整合代码作为编程接口的一部份暴露在外，应用开发者有按自己需求装配服务的弹性。这个特点使你能够组合自己的轻量级应用服务器。Spring的一个普遍用法就是将Tomcat和Hibernate组合在一起支持数据库驱动的web应用。在这种情况，Spring本身提供事务服务，Hibernat提供持久化服务——这种设置创建了一个袖珍型的应用服务器。
EJB3.0应用服务器典型地不提供这种根据需求任你挑捡服务的弹性空间。大多数时间，你得到的只是一系列包装好的特性，其中一些你可能根本就不需要。但是如果应用服务器像JBoss一样提供一个模块性的内部设计，那么你可以只取其中一部分，而把不必要的部分剥去。在任何情况，去自定义一个功能强大的应用服务器是没有什么价值的。
当然，假如应用已经超过单个点，那么你应该加入常用服务器上的服务，例如，资源池（resource pooling），消息队列（message queuing）和集群（clustering）。就总体的资源消耗而言，Spring解决方法和其他EJB3.0解决方法一样是重量级的。
在Spring框架里，具有弹性的服务装配使得将虚拟对象而不是真正的业务对象绑定到应用中做脱离容器的单元测试更简单。在EJB3.0应用中，大多数组件都是简单POJO，他们可以很容易地在容器外被测试。但是对于与容器服务相关的对象（例如持久化实实体管理器EntityManager）建议用容器内测试。因为这样会比虚拟对象测试方法更简单，强壮及准确。
XML Vs.注解
从应用开发者的观点上来看，Spring的编程开发接口主要基于XML配置文件而EJB3.0广泛地应用Java注解。XML可以表达复杂的关系，但是它也冗长且不够健壮；注解简单明了，但是很难在注解里表达复杂或继承性的关系。
Spring选择XML或EJB3.0选择注解都是有他们两者框架后的体系结构决定的。因为注解只能容纳很少的配置信息，只有整合前的框架（重头戏都在框架里）才可以把广泛地使用注解作为配置选择。正如我们所讨论过的，EJB3.0刚好符合这个要求，而Spring作为一个普通的DI框架并不符合。
当然，EJB3.0和Spring都相互取长补短，在某种程度上他们都支持XML和注解。例如，在EJB3.0中，XML配置文件作为一个可选的重载机制来改变注解的默认行为。注解也可以配置一些Spring服务。
通过例子是学习XML和注解方式之间差异的最好方法。在下面几个环节里，让我们来看看Spring和EJB3.0是怎样提供关键服务给应用的。
声明性服务
Spring和EJB3.0都将运行时服务（例如，事务、安全、日志和配置服务）绑定到应用。因为这些服务于应用的业务逻辑是没有直接联系，他们只是由应用本身管理。换句话说，这些服务在运行时由容器透明地应用到应用中。开发者或是管理者配置容器，准确地告诉它什么时候怎样应用这些服务。
EJB3.0运用Java注解来配置声明性服务，而Sring使用XML配置文件。在大多数情况下，EJB3.0注解方式对于这种服务更简单明了。这里有一个在EJB3.0中将事务服务运用到POJO的例子。
public class Foo {
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public bar () {
// do something ...
}
}你也可以为一个代码段声明多个属性，应用多个服务。这是一个在EJB3.0里同时应用事务和安全服务到POJO的例子。
@SecurityDomain("other")
public class Foo {
@RolesAllowed({"managers"})
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public bar () {
// do something ...
}
}使用XML说明代码属性和配置声明性服务会导致冗长和不稳定的配置文件。下面是一个在Spring应用中的XML片段，其应用一个非常简单的Hibernate事务到方法Foo.bar()中。