Rod和Ted,Don之间关于EJB和Spring的讨论(一)

几天前，在Don Box的博客上，我设法回答一个问题"Spring比EJB简单吗？".
现在,这个问题像是有些多余了，因为Spring和EJB的目标并不完全一致，但也许
从EJB和Spring两者所共有之处来回答，是可以的。Ted Neward在他的博客上对我
的回复进行了评论,我现在去回应一下他的观点。
    Ted评论:
        Spring是一个比EJB简单多了的框架，因为Spring更多是用基于POJO(Plain
Object 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容器可以很快启动。

   

--------- Translated by Ryan Feng

 

查看本文来源