EJB 3.0和Spring的抉择

EJB 3.0和Spring在传递POJO服务时采用了完全不同的方法，这使得开发者在实施POJO时不得不进行艰难的选择。

对于POJO的开发，存在着两种框架EJB 3.0和Spring，这两个框架组件的核心设计理念是相同的：把中间件服务传递给松散耦合的简单旧式Java对象（POJO）。这些框架组件通过在运行时截取执行内容或向POJO注入服务对象，把应用程序服务与POJO捆绑在一起。POJO本身不关心捆绑的过程，并且对框架组件几乎没有依赖。其结果是，开发者可以聚焦于业务逻辑，个人可以在没有框架组件的情况下测试他们的POJO。此外，由于POJO不需要从框架组件中继承或实现框架组件接口，开发者建立继承结构和构建应用程序的时候都有高度的灵活性。

但是，尽管两者的设计理念是相同的，它们传递POJO服务时却采用了完全不同的方法。

注入方式

Spring仍然是依赖XML来注入到POJO的，XML写起来比较麻烦，虽然流行的IDE都有图形化的编辑界面，但还是很难操作，同时Spring使用XML来说明配置声明性服务，也会产生一个冗长的配置文件。这些配置文件必须在运行时才能知道其中的错误，哪怕是一个大小写的问题。因此Spring目前也在考虑如何简化XML配置文件。

EJB 3.0使用Annotation，这要比Spring简单明了，但其功能也受到一定的限制。Spring基于XML配置的依赖注入语法复杂，但功能却非常强大。可以将任何一个POJO注入到另一个POJO，包括应用程序中自定义的那些POJO。

松散耦合度与服务集成

Spring与应用服务器采取松散耦合，作为Spring设计的核心理念，这样增强了Spring的灵活性，但同时也增加了开发的复杂度，因为如此一来，开发者就必须弄清楚Spring对应的应用服务器的。而事实上，这些与应用服务器的关联代码对于开发者大都是不必要的，开发者往往只需要关系业务逻辑就可以了。使用Spring的声明式事务服务来管理Hibernate事务，必须在XML配置文件中明确的配置Spring的事务管理器（TransactionManager）和Hibernate SessionFactory对象。

EJB3.0框架与应用服务器结合较紧密，服务被集成封装，隐藏在EJB接口后面。因为EJB3.0本身就是J2EE标准的一部份，因此，它与其他J2EE服务如JCA，JMX都结合的很好。而缺点也正是结合太紧密，不够灵活。

对Web框架的支持度

Spring在这方面要优于EJB3.0，几乎所有开源项目都有这个特性——对现有的流行技术支持度都非常好。Spring可以灵活地集成各种Web框架和模板语言，另外自身也提供了相当强大的Spring-MVC框架，而且可以很好的结合spring webflow，webwork，struts等。同时随着Spring Web Services 1.0正式公布，Spring对web service开发明显增强了，这无疑使Spring爱好者开发者更加热衷于Spring。

EJB3.0标准集成JSF，但JSF目前并不成熟，也没有得到预期的效果。同时EJB3.0对其他web框架支持也比较差。

开源与标准规范

Spring框架是开源项目，但不是标准的。Spring的接口配置文件描述都是私有的。虽然，Rona 声称Spring完全支持可以不使用Spring的特殊专有服务，但是实际情况往往不是这样的。因此，一旦使用了Spring的特殊服务，那么就绑定到了Spring框架上了。例如，如果使用它的管理服务，则必须使用相应的Spring私有的API。而且，Spring的发展完全依赖于Spring开源项目，这使得它的支持力度也不够。

EJB3.0是完全公开的规范标准，它本身是J2EE标准的一部分，因此得到了很多厂商的支持。例如，JBoss在EJB3.0刚出来时，就宣布其新的版本支持EJB3.0的服务器。这样基于EJB3.0的程序就可以比较轻松地在WebSphere、WebLogic以及JBoss之间进行切换（除非使用了应用服务器提供的专有组件）。

查看本文来源