首页 > 学院 > 开发设计 > 正文

POJO应用框架:Spring Vs. EJB 3.0

2019-11-18 13:00:06
字体:
来源:转载
供稿:网友

  爱因斯坦曾经说:“任何事情都应该越简单越好,而不是比较简单。”实际上,科学真理的目的就是在假设的前提下去简化一个理论,这样,人们可以去关注真正重要的问题。在企业软件开发中,道理是一样的。
  
  简化企业软件开发的一个要害是,提供一个这样的应用框架:它可以使开发人员不用关注于很多复杂的问题,比如事务处理、安全和持久化等。一个设计良好的框架将提升代码的可复用性,提高开发者的效率,并得到更高质量的软件。然而,目前J2EE 1.4下的EJB 2.1 框架被广泛认为是设计较差而且过度复杂的。不满足于EJB2.1框架,java开发者使用了很多其他的中间件服务产品。最值得关注的是,以下两个框架吸引了大量开发者的爱好和积极反馈。这两个框架很可能成为未来企业JAVA应用开发框架的选择。
  
  SPRing框架是一个广受欢迎的但是非标准的开源框架。它主要由Interface21公司开发和控制。Spring框架的体系结构是基于注射依靠(DI)模式。Spring框架使用了大量的xml配置文件,它可以独立应用,或者在现有的应用服务器上工作。
  
  EJB 3.0框架是JCP定义的并且被所有主流J2EE提供商支持的标准框架。EJB 3.0规范的预发布版本目前已经有开源的和商业的实现,如JBOSS和Oracle。EJB 3.0大量使用了JAVA注解(Java annotations,是JDK1.5提供的新功能。译者注)
  
  这两个框架有着一个共同的核心设计理念:它们的目标是为松耦合的POJO类提供中间件服务。框架通过在运行时截取执行环境,或将服务对象注射给POJO类的方式,将应用服务和POJO类“连接”起来。POJO类本身并不关注如何“连接”,而且也很少依靠于框架。这样,开发者可以将注重力集中在业务逻辑上,可以对他们的POJO类进行与框架无关的单元测试。并且,由于POJO类不需要继续框架的类或实现框架提供的接口,开发者可以在更加灵活性的基础上构建继续体系,和搭建应用。
  
  尽管有着共同的理念,但这两个框架采取了不同的方式来提供POJO服务。由于已经出版了大量的比较Spring与EJB2.1或者EJB3.0与EJB2.1的书籍和文章,而没有关于比较Spring和EJB3.0的认真研究,因此,本文将考察它们之间几个要害的不同,讨论他们优缺点。本文谈到的主题同样适用于其他不太有名的但同样提供“松耦合POJO” 设计的企业中间件框架。我希望,这篇文章可以帮助你选者最合适的你需求的框架。
  
  提供商无关性
  
  开发者选择JAVA平台的一个最重要的原因就是它的提供厂商无关性。EJB 3.0是一个被设计为对提供商没有依靠性的开放的标准。EJB 3.0规范由企业JAVA社区的主流开源组织和厂商共同编写和支持的。EJB 3.0框架使开发者的应用程序实现可以独立于应用服务器。比如,JBoss的EJB 3.0的实现是基于Hibernate的,Oracle的EJB 3.0实现是基于TopLink的,但是,在JBoss或者Oracle上跑应用程序,开发者既不需要去学习Hibernate,也不需要学习TopLink提供的独特API。厂商无关性使EJB 3.0框架区别于当前其他任何的POJO中间件框架。
  
  然而,就象很多EJB 3.0的批评者很快指出的一样,目前EJB 3.0规范正在编写还未完全完成最终发布版。很有可能,还需要1至2年,EJB 3.0才会被主流J2EE厂商完全接受。但是,就算你的应用服务器本身不支持EJB 3.0,你也可以通过下载和安装一个“可嵌入的” EJB 3.0产品,来使你的应用服务器支持EJB 3.0应用。比如,JBoss“可嵌入的” EJB 3.0产品是开源的,它可以运行在任何兼容J2SE-5.0环境下(如你的应用服务器),目前处于Beta版测试中。其他厂商同样可以快速发布他们自己的可嵌入EJB 3.0产品,非凡是规范中“数据持久化”部分。
  
  另一方面,Spring一直是一个非标准的技术,而且在可以预计的未来仍将如此。尽管你在任何应用服务器都上可以使用Spring框架,但基于Spring的应用仍然被限制于Spring本身和在你的应用中使用到的Spring提供的各种非凡服务。
  
  由于Spring框架是一个开源项目,因此,它使用的配置文件XML格式和开发接口都是私有的。当然,这种限制不仅体现在Spring框架中,其他任何非标准产品都会有这种限制。但是,你的Spring应用的长期生存能力将依靠于Spring项目本身(或者说Interface 21公司,因为它雇佣了大多数的Spring核心开发人员)。并且,假如你使用了Spring提供的非凡服务,如Spring事务治理器或者Spring MVC,你同样被限制于Spring提供的API。
  
  并且,Spring应用是知道后端服务提供者的(即应用程序是知道服务提供者的,这样应用程序将会在一定程度上依靠于服务提供方:译者注)。例如,对于数据持久化服务,Spring框架提供了不同的DAO和模板Helper类,用于JDBC、Hibernate,、iBatis和JDO。这样,假如你需要改变一个Spring应用的持久化服务提供者(如,从JDBC换到Hibernate),你将需要重构你的系统应用代码,来使用新的Helper类。
  
  服务整合
  
  Spring框架是建立在应用服务器和服务库之上,它的服务整合代码(如数据访问模板和Helper类)是基于框架的,并暴露给应用开发者。相反,EJB 3.0框架是紧密整合到应用服务器中的,它的服务整合代码是封装在一个标准的接口下的。
  
  因此,EJB 3.0厂商可以轻松的优化整体性能和开发者体验。如,在JBoss的EJB 3.0实现中,当你通过实体治理器持久化一个实体BEAN POJO时,Hibernate session事务将在JTA事务提交时自动提交。通过使用简单的@PersistenceContext注解(例子参看后面文章),你可以甚至可以将实体治理器和其下的Hibernate事务绑定到一个有状态的session bean上。应用程序事务可以在一个session中跨越多个线程,在事务性的WEB应用中这是非常有用的,如多页面的购物车。
  
  基于EJB 3.0 框架、Hibernate、和JBoss 内部Tomcat的紧密整合,上面提到的简单的整合的编程接口是可能的。Oracle的EJB 3.0框架和它内部的Toplink持久服务可以达到同样层次的整合。
  
  EJB 3.0中整合服务的另一个好例子是集群支持。假如你部署一个EJB 3.0应用到一个集群服务器,所有的故障切换、负载均衡、分布式缓存、和状态复制服务对于应用程序来说,都是自动完成的。集群服务被隐藏在EJB 3.0编程接口之下,对于EJB 3.0开发者来说,这些服务都是完全透明的。
  
  在Spring中,优化框架和服务之间交互更加困难一些。例如,想要用Spring的声明式事务服务来治理Hibernate事务,必须在XML配置文件中明确的配置Spring的事务治理器(TransactionManager)和Hibernate SessionFactory对象。Spring应用开发者必须自己治理跨越多个HTTP请求的事务。并且,没有简单的方法可以在Spring应用中实现集群服务
  
  服务聚合的灵活性
  
  由于Spring中的服务整合代码是作为编程接口暴露给应用开发者的,因此开发人员可以根据需要来聚合多个服务。这个特性使你可以集成一个你自己的“轻量”级应用服务器。Spring的一个通常的用法是将Tomcat和Hibernate连接起来来支持简单的数据库驱动的WEB应用程序。在这种情况下,Spring本身提供了事务治理服务,Hibernate提供了持久化服务,这种设置本身就创建了一个小型的应用服务器。
  
  通常,EJB 3.0应用服务器不提供给开发者这种按照你的需要来选择服务的灵活性。大多数情况,你会得到一系列已经预先打包好的特性,其中有些你可能是不需要的。然而,假如应用服务器提供了模块内部的独特设计,就象JBOSS一样,你可以不去关心这些不必要的特性。在任何情况下,去定制一个全功能的应用服务器并不是一个琐碎而没有意义的工作。
  
  当然,假如一个应用不是一个单一的结点,你将需要连接多个应用服务器提供的服务(如资源池、消息队列和集群)。这种情况下,从总的资源消耗上看,Spring框架就和任何EJB 3.0方案一样是“重量级”的。
  
  为了进行容器外的单元测试,Spring的灵活的服务聚合也可以来连接假对象,来替代真的服务对象。在EJB 3.0应用中,大多数的组件都是简单POJO,他们可以轻易进行容器外的单元测试。但是,假如要测试与容器服务相关的服务对象(如持久化实体治理器),更好的方式是进行容器内的测试,因为这样比使用假对象来替代的方式更加轻易,更加健壮,而且更加准确。
  
  XML vs. 注解
  
  从应用开发者的角度来看,Spring的编程接口主要基于XML配置文件,而EJB 3.0则大量的使用了JAVA注解。XML文件可以表达复杂的关系,但是它们更加冗长而且不健壮。注解的方式很简单明了,但是很难去表达复杂的或者继续性的结构。
  
  Spring和EJB 3.0分别选择了XML和注解方式,这取决于框架的体系结构:由于注释只能描述相当少的配置信息,只有一个预先整合好的框架(如大多数重要事情已经在框架中实现了)才能大量的使用注释作为它的配置选项。象我们讨论的一样,EJB 3.0满足了这些要求,而Spring作为一个一般的注射依靠框架,它没有做到这一点。
  
  当然,由于EJB 3.0和Spring相互学习了很多特性,所以,它们都在某种层次上支持XML和注释。例如,EJB 3.0中可以应用XML配置文件来作为一个选择性的机制,用来改变注释的默认行为。注释也可以用来配置一些Spring服务。
  
  研究XML和注释直接区别的最好的方式就是通过例子。在下面的几节中,我们将一起看一下EJB 3.0和Spring是如何为应用程序提供要害服务的。
  
  声明式服务
  
  EJB 3.0和Spring都将运行时服务(如事务治理、安全、日志、消息、和信息服务)连接给应用程序。由于这些服务同应用程序的业务逻辑并不是直接相关的,因此,它们不被应用程序本身来治理。相反,这些服务被服务容器(如EJB 3.0和Spring)以不可见的方式在运行时提供给应用程序。开发人员(或系统治理员)通过配置来告诉容器什么时候,以怎样的方式来

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表