我对EJB的看法

04-10-24 Missen
个人认为面向中间件的开发技术恐怕慢慢会被面向服务的技术取代,无论从商业模式还是在代码的安全性、版权的管理方面恐怕面向服务的思想都更胜一筹。看过banq的书和一些文章,感觉banq对EJB极端的推崇,甚至有些简单的系统也推荐使用EJB技术,个人表示有些不解...,(呵呵,是不是太痴迷于EJB了)

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

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

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

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

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

anonymous
2004-10-25 21:32
> 多谢,我个人认为,学习使用了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。”另一个人说:“你不应该迷信任何技术,你唯一应该坚持的是面向对象的原则,你唯一应该相信的是来自实践的证据。”我不知道你愿意认为何者是浮夸成风。

dabb
2004-10-26 12:50
也许不是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的曾经是大部分企业应用的首选方式,即使是现在也不失其魅力。

dabb
2004-10-26 12:54
不知道楼主提出的SOA是什么意思?soa本身只是一种接口分布的形式而已,在soa接口后面仍然需要的是具体的实现,不管它是基于ejb框架还是基于专有的pojo实现。

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

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

dabb
2004-10-26 14:30
ggix的批评是比较尖锐些。:)

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

napoleonn
2004-10-26 15:44
大部分辩论都不能把对手驳倒,呵呵,所以没什么意义。

讨论用哪个,不用哪个没什么意义,还是到框架背后去看看他们怎么实现自己思想的,这个显的更有意义。

zdbj2ee
2004-10-28 08:34
ejb不是为了可缩放性和面向方面编程的为一选择,看看spring的实现我想

用过spring和ejb的朋友,都能明白.

如果项目要求用rmi 分布式我想ejb是最佳。如果不是这样,我想你应该认真想想分布式ejb的效率.而且ejb的开发太重量了,实现一个业务方法需要大量的类和接口,而spring用一个接口和实现就可以了,再使用spring的ioc和aop我想不比ejb差吧.

SportsBaby1980
2004-10-28 09:30
怎么现在还有人在争论这个问题?

SportsBaby1980
2004-10-28 09:32
大部分辩论都不能把对手驳倒,呵呵,所以没什么意义。

讨论用哪个,不用哪个没什么意义,还是到框架背后去看看他们怎么实现自己思想的,这个显的更有意义。

强烈同意!

猜你喜欢