声明一点：
我不是gigix！
至于说我与他的观点相同，你倒不如说与你的观点相反罢了。
gigix的帖子我也看了，虽然一些建议显得比较苛刻 ，但是大多数观点还是正确的，只不过你听不进罢了。 我现在本着我个人的观点跟你进行纯粹的基于技术观点的讨论，没想到最后你回了一句：不想讨论了，因为你的问题都很简单。
嘿嘿，简单的问题，你反而用了最复杂的办法来解决，不是嘛 ？
j2EE规范你或许比谁都熟透，但或许这点反而成了你懒得跟别人争论的理由，反而成了“固步自封”的理由。
理论，没必要搞得玄乎其玄，OO倒是可以用似乎很高深的理论来进行辩驳的地方，不过一旦到了基于代码级别的讨论，似乎就可以彰显很多咚咚出来！
不是嘛？
另外，态度决定一切。
看了你明显糊弄一番的demo，不禁大为失望，态度就决定了一切。不是嘛？
EJB是有spec. 但似乎学院派太浓？！结果简单问题搞得较复杂，尤其是那个entity bean :(
我们以前的项目基本上是SLSB+HIBERNATE完成，感谢hibernate ：）
“高内聚，松耦合”是每个程序员（还有其它xxx员）都明白的原则吧？spring较漂亮地用IOC等等方法来解耦，也没违背这个原则吧？正因为spring简单而不失强大，才吸引了众多有反叛心的人（包括我:）
目前正试spring+hibernate, 感觉爽, 呵呵！
存在就是合理的，争论千万别伤了和气！
没必要争了，其实Spring或者叫IoC Container和EJB Container只是实现途径不同罢了，前者用BeanFactory隐藏一切，程序员直接就可以用到POJO，这种做法的好处是便于实施TDD/XP的项目，开发效率高，而后者要求Beans显式继承特定的接口，无法脱离Container来进行测试，但是EJB3已经就这些不足进行了修正，但是EJB Container的好处是显然的，它这种突出Container的优势在于更利于集群、分布式事务处理的标准化实现。看看当年的CICS就知道我们现在把时间花在架构的讨论上是多么可笑了，新技术的目的应当是提高编码效率、质量以及服务器的RAS特性。
我再次总结一下之前我叙述的重点。
例如：开发一个商店的J2EE应用系统，需要以下功能：
1. 事务机制、对象池 这属于基础功能，类似房间中的电线。
2. 商品的新增删除修改功能，这属于业务功能。
在目前的Spring中,这两种功能是并列出现在一个配置文件，简单地说：这会带来混乱的感觉，因为基础功能可能不需要经常修改；而业务功能需要经常修改，这就如同代码一样，你将多个功能代码放在一个类的方法中，这是不行的，需要进行分派封装。
我们需要拓展性，就象我们需要房间的电线可以在必要时更改一样，不必裸体，加一件衣服，就如同给电线加上排线管一样，我们给基础功能从业务功能的配置中分离出来，单独打包，需要修改基础功能时，再打开基础功能的配置文件就可以，如同人穿了衣服后，需要透明扩展，就脱了衣服就可以了
。
过了年，讲话够费劲的，我觉得我前面的帖子讲的够明白了。其实这些精神在GoF设计模式中体现很多，例如装饰模式、代理模式等。
还有关于jdonFramework的两个问题是很简单：
1. JDBCDao的Database名称，了解过EJB开发的人一看就知道，这里serviceLocator是EJB的定位器，是在EJB中用的。这个问题答案很简单。
2. 关于Cache，如果你知道GoF的适配器模式或Wrapper模式，很明显，JdonFramework使用了Wrapper模式，以便用户能够更换更好地的缓存器，缺省的是OfBIz一个缓存器，这缓存器通过配置文件，可以设置缓存失效时间，也就是说，它的缓存是自动更新的。
我觉得你们的讨论很幼稚。
某人动机也不纯正，时时提起自己的那个%%￥%￥#，
呵呵，走也
我自己浅薄，只是觉得ejb的那古怪的oo模式很令人难以接受，而叛逃了。现在ejb3.0这方面有了改善，所以打算回归。
至于别的，谁愿意当技术杂工阿！什么东西都自己拼凑甚至写。反正我没这个水平。spring阿！拿来做个bean工厂就够了。别的太累。别告诉我他有多好，灵活，可扩展，我懒。
那个灵活，可扩展是破坏整体性得来的。条块化，固然隔离了风险，也增加装配的问题。用一个整块的石头做的东西比拼起来的东西结实的多。结晶的时候方向一致嘛！所以大一点的组件更好用，更结实。spring里面东西太碎了。所以懒人我不用。
深思与学习中。。。
ejb
111111
tmd,怎么一提ejb就有人吵架。现在叫ejb不好的人两年前估计大部分都是对ejb顶礼膜拜吧。现在ejb2.0的那些缺点早就是大白菜，谁都知道了，也没必要再一直说了。
spring和ejb，从框架的角度来说是，#$#$@tmd,没意思，不说了
by the way,人家开发出一套东西来，即使是有缺点，也没有必要老是进行攻击吧，看来”文人相轻“的毛病还是改不了。你要用的方便就去用，不方便就自己写了。
〉存在的就是合理的
太对了，就像马家决，他的事是存在的，就是对的，即使他残忍。因为对他来说，有比他更残忍的东西存在----他的环境。
***是存在的，说明它有它的优点，不能因为缺点而否定优点。相反，***还是当今的主流，我们在没有发现其优点之前，不能对他否定，而应该努力去发现他的优点。
菜鸟回帖 有心无力
（*** == ejb）
哈哈，当初写篇东西本出于一片玩笑，不过是因为javaeye上对spring太多偏颇的缘故，仁兄评论的极是，都是打中中要害。不过我是不屑于拾人牙慧的，要批就批出新意:
ejb 2.x尤其是ejb2.x cmp entitybean是个极为垃圾的东西，倒不是因为别的，是因为他险些破坏坏了j2ee component architecture内在的哲学根本。整个j2ee component architecture是构建在catalysis方法上的一种component & connector style的架构。catalysis的方法精髓在于对象，行为，协作都作为first class进行考量，结构也是role/use case/domain的形式架构。ejb 1.x极好的复合这个思想，而在ejb2.x里，exprt group里的人开始考虑简化ejb的开发，于是作了大胆的推正:既然80%的enterprise系统是构建在RDBMS上的，那么持久模型最终会转化为er模型，那么只要可以很好支持e/r模型的持久，就可以满足80%的enterprise应用。于是ejb 2.x cmp entity bean完整的支持了er建模而非oo建模。结果违背了catalysis方法的本意。catalysis希望在oo的domain object上发掘协作，而不是在纯数据化的er上发掘。因此如果ejb 2.x成功，那么j2ee component就完了，它失败了，甚幸！甚幸！
题外一句，评价一个组件结构，先看内在哲学一致，然后是c&c实现的便利性，spring此处甚优。所不足者，约定和语义。ejb语义完备，可惜实现的很垃圾，两个互补所长才对。这才是我的论点。兄略偏颇了。
望与兄深议，加我msn : binartist@hotmail.com
哎呀，没引用上，上言对qnab001兄说的
EJB/SPRING并不矛盾. 我们完全可以结合他使用.
我们现在就是把spring跑在EJB里面.
开发过程最强掉可测试性
应用强掉的是事物性, 把他们结合, 有什么不可以呢.
在一个有上千个EJB的项目中, 编译和部署是一件痛苦的事情. 这点我深有体会, 我们的应用在编译需要花上6分钟时间, 部署更是慢的要命.
有了SPRING, 我完全可以避免他的冲突.
再说了,
我们需要是快速的开发能力和简单的测试方法.
通过使用delegate模式, 我可以在测试中走POJO的模式, 在生产环境使用ejb事物. OK
这个帖子非常的好，哲学问题加精彩辩论，只是火药味有点浓，RPWT凸现；个人更加欣赏java视线robbin的个性和论坛的氛围，呵呵