我对EJB的看法

多谢，我个人认为，学习使用了EJB，才会对整个企业系统有一个通盘全面的了解，一个企业信息系统到底需要考虑哪些因素，这个对于初学者很重要。

这也是我反复推荐EJB的原因，或者说得再极端一点，只有你了解了EJB，你才有资格谈面向服务，EJB是基础，以前有些知识必须你只有做了项目才知道，现在不必了，你只要学习EJB，都在里面了，所以不要害怕其复杂，因为他考虑了小中大系统等系统的可伸缩性。

至于具体项目是否使用EJB，试想一下，如果你有EJB复杂知识经验基础，你是否对项目中是否使用EJB才能把握得更清楚，知己知彼，百战不殆。

我极端推崇EJB主要是针对国内程序员浮夸之风而做的，或者再说一句不客气的话，等你研究透精通了EJB，才真正能理解国外目前最新技术的来龙去脉，才有资格论三道四。

希望大家能正确理解我的本意，我推荐EJB与你是否在实践中使用是两回事，因为我希望你是一个有架构知识的判断力的人。

> 多谢，我个人认为，学习使用了EJB，才会对整个企业系统有?
> 个通盘全面的了解，一个企业信息系统到底需要考虑哪些因素
> 飧龆杂诔跹д吆苤匾?
>

换句话说，1998年以前根本没有所谓“企业信息系统”，或者说1998年以前根本就没人知道“对整个企业系统有一个通盘全面的了解”。难道你认为这会是事实的真相吗？再换句话说，.NET的用户们、Python的用户们直到今天也没弄清楚“一个企业信息系统到底需要考虑哪些因素”，难道你认为这会是事实的真相吗？

> 这也是我反复推荐EJB的原因，或者说得再极端一点，只有你?
> 解了EJB，你才有资格谈面向服务，EJB是基础，以前有些知识
> 匦肽阒挥凶隽讼钅坎胖溃衷诓槐亓耍阒灰EJB，都
> 诶锩媪耍圆灰ε缕涓丛樱蛭悸橇诵≈写笙低车认
> 统的可伸缩性。
>

“面向服务”，面向谁的服务？EJB提供了哪怕任何一样服务吗？remoting是谁提供的？是RMI/IIOP。事务管理是谁提供的？是JTA/JTS。安全性是谁提供的？是JAAS。连通性是谁提供的？是JCA。服务都是J2EE infrastructures提供的，EJB仅仅是便于使用infrastructure的一条捷径而已。使用服务的捷径难道就是服务本身吗？

> 至于具体项目是否使用EJB，试想一下，如果你有EJB复杂知识
> 榛。闶欠穸韵钅恐惺欠袷褂EJB才能把握得更清楚，知
> 褐耍僬讲淮?
>
> 我极端推崇EJB主要是针对国内程序员浮夸之风而做的，或者?
> 说一句不客气的话，等你研究透精通了EJB，才真正能理解国?
> 目前最新技术的来龙去脉，才有资格论三道四。
>

唔，一个人说：“只有你精通了xxx，你才有能力xxx、有资格xxx。”另一个人说：“你不应该迷信任何技术，你唯一应该坚持的是面向对象的原则，你唯一应该相信的是来自实践的证据。”我不知道你愿意认为何者是浮夸成风。

也许不是ejb率先提出以下概念，但ejb确实提供给我们很多方便的编程特性，比如天然的面向interface的bo编程习惯，cmt等等。在设计模式上也整理了很多有用的概念，象servicelocator,dao,business deletegate等等（虽然这些不是ejb专用的，但我确实是在应用学习ejb的过程体会到这些的好处）。虽然ejb本身也有不少缺点，很多是因为在和ejb容器关联的太死的缘故，造成不方便测试，限制了oo编程等等，但这些都是可以曲折克服的，而且ejb本身也在进化之中，ejb3.0草案已经注意到它广受批评的那些弱点，提出改进意见。之不过这种产业化的specification的推出一向是太慢。总之是不喜欢对某种技术一棍子打死。ejb确实在企业应用中提供了一个很好的编程框架，方便了很多工作。只不过现在有了一些象spring之类的对于很大一部分应用来说更方便(相对于ejb)，更自然的框架。所以ejb的弱点也就更加突出而已。我不知道在象spring这些通用的现成的框架（或则有人也许说应该叫容器）出现以前，大家如果不用ejb是怎样设计整个技术框架的，就拿面向接口的编程方式来说，或则是自己编写专用的基于xml的框架，或则是通过proxy,factory等方法来实现，对于cmt之类的特性，在aop出现以前又有多少人能自己实现这种方式（除了应用ejb)?所以我觉的ejb的曾经是大部分企业应用的首选方式，即使是现在也不失其魅力。

不知道楼主提出的soa是什么意思？soa本身只是一种接口分布的形式而已，在soa接口后面仍然需要的是具体的实现，不管它是基于ejb框架还是基于专有的pojo实现。

>>我不知道在象spring这些通用的现成的框架（或则有人也许说应该叫容器）出现以前，大家如果不用ejb是怎样设计整个技术框架的，就拿面向接口的编程方式来说，或则是自己编写专用的基于xml的框架，或则是通过 proxy,factory等方法来实现，对于cmt之类的特性，在aop出现以前又有多少人能自己实现这种方式（除了应用ejb)?所以我觉的ejb的曾经是大部分企业应用的首选方式，即使是现在也不失其魅力。

恩，说得好。这就好象在说：在汽车出现之前，大家如果不坐马车又怎么能出去旅游呢？所以我觉得，马车曾经是大部分人旅游的首选方式，即使是现在也不失其魅力。恩，实在是很有道理，佩服佩服。

ggix的批评是比较尖锐些。：）
其实到现在我还看到不少人在学ejb,ejb集中了很多企业应用方面的概念（当然很多东西是属于j2ee这个大的概念中），所以从中是可以学习到不少东西，即使不采用。不能一棍子打死，而且在分不式领域里还没有更好的通用框架与之竞争(java领域）。你不能说现在有了属于setter,constructor方式的ioc,就彻底排除jndi了啊。。当然我自己现在对于一般的应用都倾向于使用spring,感觉确实很“优美”，而且很“轻”。

大部分辩论都不能把对手驳倒，呵呵，所以没什么意义。
讨论用哪个，不用哪个没什么意义，还是到框架背后去看看他们怎么实现自己思想的，这个显的更有意义。

ejb不是为了可缩放性和面向方面编程的为一选择,看看spring的实现我想
用过spring和ejb的朋友,都能明白.
如果项目要求用rmi 分布式我想ejb是最佳。如果不是这样,我想你应该认真想想分布式ejb的效率.而且ejb的开发太重量了,实现一个业务方法需要大量的类和接口,而spring用一个接口和实现就可以了,再使用spring的ioc和aop我想不比ejb差吧.

怎么现在还有人在争论这个问题？

大部分辩论都不能把对手驳倒，呵呵，所以没什么意义。
讨论用哪个，不用哪个没什么意义，还是到框架背后去看看他们怎么实现自己思想的，这个显的更有意义。

强烈同意！