几天前，在Don Box的博客上，我设法回答一个问题"Spring比EJB简单吗？".现在,这个问题像是有些多余了，因为Spring和EJB的目标并不完全一致，但也许从EJB和Spring两者所共有之处来回答，是可以的。Ted Neward在他的博客上对我的回复进行了评论,我现在去回应一下他的观点。
Ted评论:Spring是一个比EJB简单多了的框架，因为Spring更多是用基于POJO(PlainObject Old Object)的方案，但对于"一些情况"下，它并不简单,而是更复杂。
Rod:好的,在"一些情况"下,地球是扁平的对吧。在我的经验中，如果实现业务逻辑所需要的java Object超过3个的时候，认为用POJO(通常有一个接口)方案更复杂的人很少：给我印象深刻的是，那些否定POJO方案的那些人，真正尝试两种方案并做出对比的人为零。可能他们有自己的观点，但我并不知道。(也许直接的事务和远程方法更另人愉悦？)我真的非常希望看到能真正证明基于POJO的方案更复杂更难用的评论。
Rod:为什么Spring比EJB简单易用?我不能给你一个独立的主观臆断，我可以告诉你的是，我是借鉴EJB，并运用我多年的经验来设计Spring的，我也很乐于去比较.从一开始，Spring(或者其他的IOC加Services框架)框架就是和你的业务代码隔离的，没有藕合的.这个区别是很有重大意义的。任何Object可以被事务化而不需要陷入EJB的丛林中。这对于代码的重用也是有意义的。实际上，在你自己的业务对象中，很少有框架的侵入，换句话说，你会有更多的自由去运用面向对象的分析设计。
Ted:哦，我已经说过了，企业级系统通常不是来练习OO(面向对象),因为那么做有一种让我们陷入麻烦的危险趋势----这也就是为什么人们在网络计算的趋势下，使用CORBA,DCOM和RMI来解决问题的原因。你应该考虑一下，把collection置于服务器端，iterator放在客户端的意义，然后你就明白.....
Rod:Ted,我提到的"更多自由去使用OO",并不是说所有地方都用OO,当然，分布式对象是很需要的。但重要的是，不要把"企业应用"和"分布式应用"混为一谈. 应用程序的内部结构应该尽可能的面向对象.然后提供一个高层的接口对远程调用暴露，理想状态下，仅仅这个接口才可以放弃面向对象.(基本上像SDO--服务数据对象Service Data Objects这样的解决方案在这部分是很庞大的).所以在分布式对象建模中，在应用内部引入优秀的应用程序接口(虽然破坏OO)是没有争议的。Spring和其他的IOC(inverse of control控制反转)容器，不会在OO方面设置障碍,而EJB就没做到，它大范围内地依赖了EJB的接口和框架。
在我对于Spring的XML配置要比EJB复杂的部署描述文件简单易配置的评论后----Ted写到:公正地说,Rod--JSR 175 在简化部署描述配置(包括你的Spring的XML配置)方面的所做的工作是有意义的(而不是所有),在java5之前，部署描述文件是一个必须的，很恼人的事情吗？不幸的是，事实表明，考虑到所有的可能性，这已经是最佳的解决方案了。(所有人都记得EJB1.0时，基于对象的描述符)。
Rod:没错,JSR-175会在DD(Data Define数据定义)方面进一步改善(已经有所改善，虽然注释被一再过度使用,不过那是另一个话题了).不错，DDs(数据定义文件)是必要的，虽然很繁琐，这是java借用C#中属性集/注释的想法而来的.但问题是,现在的EJB部署描述让人惊骇地冗长，差不多全在XML里.而且一个标准的ejb-jar.xml部署描述文件并不够，通常需要两个。相反，Spring的配置文件短小精悍，而且不需要额外的引用。当然，EJB3.0不在这里讨论，因为我想评论的是现在使用EJB的方案(直到2006或者JSR-220完成的时候)。
在Don的博客上，我对他拿Spring进行的测试表达了我的尊敬:
Rod:因为你的代码不是严重依赖于容器的，所以可以方便的进行单元测试，比如用JUnit。这样一来，和过去传统的J2EE容器内测试方案比起来，提高了巨大的效率。你也可以在Spring容器上做集成测试，而不需要一个重量级的J2EE应用服务器----不像其他应用服务器，Spring容器可以很快启动。
Don:我仅仅是说尽量少的依赖于容器，EJB并不是一个完全失败的技术，用OpenEJB容器效率并不会很低的，至少从我的测试来证明。
Rod:我并不确定像OpenEJB这种轻量级的EJB容器会是一个另人满意的解决方案.我没有遇到有人用过它，我自己也没用过。真正的EJB测试总是繁杂的，通常需要五分钟一个编码/测试循环。
Rod:比较一下Spring的Pet Store例子和EJB方案的，就可以发现,在Spring的例子中，很少有冗余的代码，也就是说什么都不做的代码...
比如Service接口,JNDI服务查询操作等等.在我接触的项目中,用一个Spring+Hibernate的混合框架，至少能拿去EJB方案的10%---20%的代码,对于项目的提交和后期维护是有重大意义的.
Don:我来说说我的观点,简单并不永远是好的，不幸的是，它仅仅代表简单，没有JNDI，就等于说牺牲了管理人员在不重启服务器的情况下，对配置进行调整的需要。这可能对于一些客户的应用来说不是太重要，但对于一个24*7的应用来讲就是个大问题了。
Rod:当然，我说的用Spring终结你代码中的"服务接口，JNDI查找",并不是说真的不用JNDI,比如说，你还是希望调用EJB,Spring可以给你创建一个代理，封装了JNDI查找啊。
在Pet Store的例子中，我尽力寻求一个简单的架构--既然我们来讨论Pet Store,关键的就是，Spring和其他轻量级的框架技术，给了你一个简易框架的选择。如果是传统的J2EE,你想创建一个Pet Store,你最好是用Perl或者.Net,或者抛弃J2EE的高级特性，只选择Servlet和JSP,所以有一个你自己的简易架构是必要的。
没有JNDI，就等于说牺牲了管理人员在不重启服务器的情况下，对配置进行调整的需要",嗯，有多少需要用JNDI重新配置应用的需要?更好的解决方案是JMX,但应用服务器并不了解你想做什么有意义的配置，同时Spring 1.2已经加入了对JMX的支持,这将方便开发者去操作应用对象和配置。比如说，改变一个JNDI的环境变量是我们很少要做的事情.开发者通常会很准确地配置这些信息，来避免修改的痛苦。(我同意，这可能是个不好的假设，但确实通常是这样的)，你如果想通过JNDI来改变某个值，你已经知道何时来找到它,等等。
Don:请记住，EJB提供双机事务的支持，而Spring没有，这一点让我不安，Spring失去了它的亮点。
Rod:Spring不会做或者很少做双机事务,不知道怎么就确定Spring失去它的亮点了,Spring的事务层抽象是在事物策略的基础上的一层，一个方案就是JTA,在这种方案下，双机事务来自于应用服务器底层的支持，而不是Spring.实际上,JTA事物策略是我们最早就重视并实现的功能。我明白，在一个无JTA支持的简单容器下，丢弃一个落后的local和global事务编程模型是很有意义的.