EJB的狐疑：组件与可重用性的抵牾

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年后才需要的扩展性。同样现实中在这一技能擅长的规模，至少今朝还无法找到更强大的竞争者。技能选择是应用型的技能人员永恒的主题，雷同的狐疑会不绝的呈现，最重要的是认同它们的抱负和方针，保持对它们客观清醒的认识。放到擅长的规模的技能才是最美妙的，这和人生没有什么两样。