EJB的困惑:组件与可重用性的冲突[Java编程]

EJB技术正在像其他光辉过的技术一样走到了一个关口.2000年从前这项技术充满了传奇色彩,被大批企业不假思考地承受.但是抱负毕竟是抱负,经过了几年的发展,本日这项技术却正在被猜疑大概至少说让技术人员犹豫不决,实际的是J2EE的对手出来了,.NET仿佛又有着后发的技术上风.大部份的探究和争辩已经开始转向这两个体系构造的比较.Java阵营内部一样发出了猜疑的声音,最直接的就是对EJB的攻击,因为人们发现本来这项技术所做的答应仿佛都走向了相反的方向

1．大量的案例由于采取了这种技术反而使得系统开辟日益复杂,而不是想像的简化开辟周期加长成了家常便饭,实现一个进销存就把很多人难倒.

2．EJB成了高贵的代名词,而不是盼望的本钱降低

3．废了半天劲还不如用消息传送举行系统互操作

4．终究发现完好地摆脱平台是不大概的

但是Java总偿还是不错的,于是有了Spring等等N种体系.EJB开始让人们困惑.任何技术和人生一样有它的困惑期,但是EJB给人们的困惑尤为经典,更具意义.J2EE和其他体系的比较已经泛滥于网上,实际利用的经验也到处可见,以至于不需求这里介绍,但是EJB目前并未被单独地被器重这是应当值得注意的,这与J2EE发展史倒是南辕北辙的.必须承认这么一个事实,EJB是被单独提出和定义的,最早是完好单独的一种标准,这与所谓体系构造并没有直接的关系,大概说EJB的意义和目标毫不只是在J2EE内封装商业逻辑,所以过于在框架内谈论EJB,大概说认为J2EE的弱点一定要蔓延到EJB上能否符合是值得探究的.

EJB诞生的早期人们的高兴关键在于这种模子吸取了以往组件技术的精华,并有很大发展,令人们看到了健旺的商业组件制造本钱降低的盼望,分外是超越平台的可装配性和移植性,这是软件工程界一向的幻想,因为这意味着企业端计算程序计划产业化和具体分工大概要成为大概.这种思惟目前也影响了界面一级的利用,比方所谓的Portlet技术,IBM公司的WebSphere平台的技术大概不是可怕的,但是有几十个合作搭档事实上给它供应了近似的合作,这才真恰是让对手感到惊骇的.因此我们评论EJB的时刻,评论它的代价和作用,脱离了它的计划目标也就失去了更大的意义,以下的商业环境和软件技术瓶颈应当重新被审视:

1．软件工程就重用范畴来说能否超越了组件时代,大概说已经不需求组件了?

2．软件的重用能否只需求互调用而不需求反复装配,乃至装配到差别的部位?

3．商业逻辑能否仍旧需求封装,并保持健旺的特点,不中止地服务

4．组件和健旺和可用性是互联特点能代替的吗?

5．能否有更便宜的组件情势超越EJB并一样得到众多的支持?

6．.NET的组件尺度和EJB能否有可比性,大概说什么组件情势和EJB才有可比性?

当冷静地考虑的时刻就知道,技术不该该被当作明星吹捧,但一样也没有简单倒下的软件技术.EJB不成熟,但不等于可以简单被否定.是EJB使得很多普通的程序员可以参与本来贵族似的组件开辟,乃至是简单的Windows上面开辟UNIX上的组件,EJB的历史问题大大都在于将这种技术错误地滥用:一个浏览人数少的可怜广告浏览程序也要用组件,关于一个只想简单算出库存的客户计划了所谓N年后才需求的扩大性.一样实际中在这一技术擅长的范畴,至少目前还无法找到更强盛的竞争者.技术挑选是利用型的技术人员永久的主题,近似的困惑会不断的呈现,最重要的是认同它们的抱负和目标,保持对它们客观复苏的熟习.放到擅长的范畴的技术才是最美好的,这和人生没有什么两样.