From:http://blog.springframework.com/rod/
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提供2PC(两段提交)事务的支持,而Spring没有,这一点让我不安,Spring
失去了它的亮点。
Rod:Spring不会做或者很少做2PC(两段提交)事务,不知道怎么就确定Spring失去它的亮点了,
Spring的事务层抽象是在事物策略的基础上的一层,一个方案就是JTA,在这种方案下,
双机事务来自于应用服务器底层的支持,而不是Spring.实际上,JTA事物策略是我们最早
就重视并实现的功能。我明白,在一个无JTA支持的简单容器下,丢弃一个落后的local
和global事务编程模型是很有意义的.
------Translated by Ryan Feng