坚持发扬EJB、Spring的光辉思想，将组件化进行到底！

好大的标题，看似又一篇炒作滥文，其实是笔者近两年对软件架构痛苦思索徘徊后所得的经验体会，在此与诸位共勉。

EJB、Spring，这不是Java界最有名的两大冤家，何以把它们扯在一起。其实Spring乃是EJB1.x、2.x的继承者，正如EJB之前的COM、CORBA。他们的思想一脉相承，那就是企业级的组件化思想，也可称之为理想！

一、非组件化的国内软件行业

各个行业的企业总有一些核心业务，长久保持不变，新时期的新业务基本上都是围绕核心业务展开。很长时间以来，IT技术的变化与企业业务的扩展存在着很大的矛盾。当企业的新业务开展之后，如何保证原有业务稳定运行的同时，新业务能够得到IT的支持与扩展？当IT技术有重大进展后，如何保证原有业务的同时进行新技术改造？在以上两种运动中，如何重用原有的技术成果？这是每一位负责任的系统管理员、CIO与及开发商所关心的事情。遗憾的是，组件化思想及实践产生以前，这个矛盾基本上是极难解开的死结。绝大多数的做法就是重写。
譬如DOS时代，很多单位都使用了单机foxbase版的财务系统，界面虽简但稳定实用；到了Windows时代，流行VB、PB，于是系统重写；再到B/S时代，系统再次重写；到最近热炒的RIA，系统是不是要再次重写？对于很多小产商的作品而言，答案肯定是Yes。
很多同道可能会说，这样正好啊？我们才可以不断地赚钱。错！
这样的状况叫“低水平重复”，这个术语经常被国人用来痛斥社会经济领域的很多不合理现象。可惜我们这个自认为高智力的行业，很多时候就是在干这种愚事。每到技术革新，各企业要重花一次钱、重学一次操作、重转一次数据，折腾得半死；而适应不了新技术的产商，随被淘汰的代码一同退出市场；适应不了新技术的程序员，只能转行。要想不被淘汰，就必须紧跟时代风潮，不停地把精力放在新技术上，在领会业务上花的时间太少，最后导致我们的系统与企业的业务总是差半拍。因为原先快把业务搞清楚的程序员大多升官或离职了。
笔者以为这是软件界，尤其是国内软件界混乱的根本技术原因。由于技术长期得不到积累，我们不得不一次又一次吃外国的人剩饭。

那我们终究需要怎样的软件才能解决这些问题。
其实答案早就在我们身边晃了太多年，偏偏我们视而不见。大家接个新外设，要不要换主机？加根内存条、换块显卡、声卡要不要换主板？OS是不是只能用几个特定的硬件，跑几个特定的程序？而大家在OS下写的程序，是不是在系统新版本运行不了？答案基本上是否定的。
OS可以适应全世界数以万计的程序及其发展，为什么我们的应用程序不能适应哪怕一个特定单位的变化和发展。为什么我们的应用系统到了新环境下就要重写？
原因就在于我们大多数应用程序规范性太低、耦合度太高。

要提高规范性、降低耦合度，就要不断地设计、不断地分层、不断地抽象、不断地重构。当我们终有一日把有用和成熟的代码封装成jar或是dll，不仅自己能重用，别人也能重用的时候，代码其实才算合格。
现在大家都习惯用开源产品了，外国人热衷的就是不断地制造这样的零件（组件）或技术。而我们中国人，热衷的却是组装人家的零件和技术（一如其它涉及技术的产业）。很多外国人十多岁就做出了了不起的组件，而我们中国人却把“不重复发明轮子”这种搬来的话挂在嘴在，结果是既不制造旧轮子，更没有能力发明新轮子。很多人从业十多年都写着乱糟糟代码。
项目，不是说东西扔到客户手上套足了钱，拍拍屁股就走人。成功的项目，要对客户负责任。就算自己退了，也该把工作交接好。前面的工作成果后面用不上，只能说前面的工作不合格。
国内应用软件界一直在走RAD的道路，一开始吃着爽，越到后面越不是滋味。不是说RAD不能用，而是说，一上来就RAD，注定被养成懒汉，早晚沦落成编码机器。RAD诱使我们逃避思考，诱使我们逃避设计，最终让我们被早早淘汰！

二、EJB、Spring的组件化实践

在EJB之前，大家所知的COM和CORBA已然火过一头了。这说明国外企业在经过长时间的信息化实践后，已经深受上面所说“低水平重复”的非组件环境之苦。COM和CORBA的确解决了一些问题，但还没有成为那种完整、成熟的体系。所以当初EJB出来的时候，业界疯狂热炒。这一方面是商业原因，更重要的是企业及开发者对组件化的热切理想。其实EJB的确是成功地解决了很多问题，但由于一开始就定位在高端，技术上相当复杂，导致众多开发者真正未能掌握，由此而产生了很多失败的项目。

这个时候，MS的.NET开始热了起来。.NET其实整个思想体系都是参照J2EE的。不过沿袭了MS产品一贯的易用风格，中小系统实现比较容易。但凡事有利有弊，MS为了迎合初学者偷懒的心理，架构上的RAD风格是相当明显的。很多人不知不觉中又被养成了懒汉。这导致很多开发者拿着.NET这种OOP的企业级技术，继续做过去那些高耦合的系统。最终结果，不论是开发者还是公司，都将重蹈以上笔者所说的覆辙。

应该说，J2EE一上来就强制开发者考虑OOP、分层、解耦、重用，这些很复杂但最重要的事情，最终必然后落得个“曲高和寡”的结果。但如果开发者真能以程序设计作为自己的毕生事业，就一定可以在Java的世界里经过痛苦摸索，掌握软件的精髓。

而后，火热的Spring运动开始了。Rod集多年企业级开发的功力，创造性地开创了简化版的EJB：Spring Framework。这里有个前提，那就是Rod多年企业级开发的实践，包括EJB的实践。正是这个精通EJB的天才人物，才可能对EJB进行简化和发挥。国内很多人自此运动后，把EJB以至于Sun形容得一文不值，却忘了自己每天都在用Java这一伟大的语言，并实践EJB这一技术所传承的组件化思想。而初学者在不明就里的阶段，只记住了Spring的简化，却不知实践组件化的根源所在。也就是说，不是Spring不好，而是说大家应该充分领会Spring所一脉相承的组件化解耦思想，而不只盯住Spring的简化。
自此，Java界开始了无尽的混乱。人们每天都在考虑如何“简化”J2EE，以至于把J2EE简化到Web+DB，简化到PHP那样高耦合的程度，或者骑墙式的RoR。历史再度倒退，组件化面临严重危机，甚至于坚持组件化的Java也被殃及池鱼。

这里不得不称赞一下Jdon和当家人banq。其实有一阵笔者也是Spring运动的热心拥护者，对banq的EJB论调相当不感冒。待自己晕头转向了两年，重回jdon，这才体会到banq的苦心。
正如众所周知的英语学习无捷径，好的程序设计同样没有捷径。
banq这几年冒天下之大不韪，一再坚持重申这个世间最简单的真理，的确是值得敬佩的。
[该贴被lgx522于2007年05月21日 18:12修改过]

三、坚持组件化，打造真正的软件工业

软件发展到今天，其实应该并且能够进入到工业时代了。
前面所说的企业软件危机，既是技术问题，也是产业问题。

今天，地球人的各种产业都是大分工、大合作的工业化产业链。生产效率提高了，就业人群也随之增加。在封建时代，大家都搞小作坊和行会，总觉得如果放开了，分式后大家会没饭吃。但资本主义的实践表明，越是分工合作程度高的产业，规模越大。原因很简单，在生产效率提高的同时，消费被极大地刺激，以至于产业膨胀的速度仍赶不上消费。像现在的汽车，分工合作程度极高，使发达国家的人们买了一辆再买一辆，换了一辆再换一辆，结果是整个汽车产业的繁荣。

我们软件业（尤以国内为甚）其实也一样，表面上是没事可做，事实上是由于软件业整体的低效率，导致人们用不起软件，或不敢用软件。成天忙于低水平重复导致的低水平局部竞争，企业真正关心的很多需求得不到满足。长久之后企业在信息系统得到的回报太小，自然不愿意花钱在信息系统上。
其实大多数开发人员和开发商，都想充分满足客户的需求。可惜你几十号人，打个比方，如果从种橡胶、挖铁矿、到设计车型，焊接，推销。什么都要做，只怕是连小推车也造不出来的。
所以我们一定要分工合作。

现在电脑有了，OS有了，DB有了，编程语言有了，这些最难做的基础工作外国人都做了。但进入企业级领域仍有无数的工作在等着你。国人在这一点上缺乏合作精神的劣习暴露无遗。明明只是精通业务，非要对设计指手划脚；不过是分析专家，非要对不熟的技术挑三捡四；明明可以沿用原系统的精华部分，非要替换以示高明；更有不懂事的毛孩子，自以为可以用RAD搞定一切。很多国人的牛人都一种普遍的“超人”意识，老子天下第一，其他人都是垃圾。殊不知软件业太大太复杂了，再新手的同道，也有很多你不知道的重要知识和奇思妙想；再高的所谓大虾，也有无数的盲点和愚见。
所以要分工合作，一定要学会尊重他人，实事求是。

至于技术上的问题，其实以笔者愚见。至少spring已经基本上解决了“解耦”的重大难题。大家只要不偷懒，把自已写的、别人写的、书上看的，网上下的，好好琢磨透了，以spring这种大体上“无侵入”的框架装配起来，即可基本上解决组件化的难题。
至于EJB，包括现在相当简化了的EJB3，由于笔者所知甚浅，不便多述。望banq指点。

每一个程序员，不要想偷懒，努力实践解耦自己的代码。
每一个开发商，不要太急功近利，要努力提炼产品的类库，尽力与其他产商互通互联。
每一个系统管理员、CIO和企业领导更要谨记：高耦合的系统不能要、无类库封装的系统不能要，无测试的系统不能要、无类库文档的系统不能要。
这样才可以杜绝国内急功近利的低水平软件横行市场，早日迎来中国软件的组件化时代，形成健康、有秩、高效的软件行业。

nice

其实组件化开发是OO面向对象的延伸。组件化开发何RAD快速开发并不矛盾，只是体现快速性的时段性有些特殊，当随着软件越来越复杂，开发时间延长后，组件化开发就能提高后面的效率，实现越开发越快，而非组件化非OO的软件一开始很快，但是开发到后面就难以为继，最后发生软件人员离职，重新再开发，重新开发如果还是按照老思路，又走上上次悲剧。

发生这种恶性现象有两个原因：
1. 不知道，没有专业软件知识，如果不愿意再接受培训和学习，那就是愚昧。
2. 不负责任，反正我在位时，这些软件功能实现就可以，哪管他以后怎么办？这个解决就不是在软件领域内能够解决的，也不是一两天能够解决，功夫在画外了。

现在国内软件业弥漫着“大跃进”的味道。“亩产万斤”这类的技术、新闻和宣传层出不穷。
根源在于无知，尤其是各单位信息主管部门及单位领导对信息系统的不熟悉。以本人多年的系统管理维护及开发实践，有如下的体会：合格的企业信息管理者应当具备丰富的技术经验、对企业业务的准确理解，将信息技术与企业业务融合的洞察力。这也正是国外企业普通重视的CIO。

有了合格的CIO，才能保证企业的信息化沿着比较正确的方向前行，才能保证企业的信息投资获得优良的回报，最终保证开发商的健康持续赢利。
CIO的高水平，从甲方这个源头选择高质量软件，从而迫使乙方提高软件质量，而不是粗制滥造，跟风起哄。
信息化发展得比较早的国家，正是在历经长久的经验教训后，才开始重视CIO这一重要的岗位，从而逐渐走上良性轨道，走出长期被开发商着牵鼻子走的困境。自此开始，满足企业的业务需求放在第一位，保护并扩展企业业务逻辑的迫切需求造成了组件技术的繁荣。

相信国内的企业应用再经过5－10年的混乱，必将走上这条正确的道路。
要让这一天早日来临，觉醒了的同道们一定要坚持真理，并唤醒更多的彷徨者。

如果要开发一个可重用，可扩展的组件，那需要很深厚的OO技术功底．
连OO都不想学，学不好，怎么能开发核心业务组件呢？
还是先学好OOA/D/P吧！

abiandbel说的非常有道理

说的好。
国内这行的从业人员，可能很多人比较浮吧。我也算其中一个。我想多数的人都想做好，可能不知道该怎么做吧！

专心，一定要专心。
但求专精，不可贪多。笔者也曾经是一个新技术的追星族，虽然也可说是见多识广，却难有专长，直到最近才幡然悔悟，重啃老书，重构代码，这才有了一些进步。

不论学哪门技术，首先专精之后再可考虑旁通其它，万不可贪多求快，最终一事难成。
如果是搞Java，Core Java、Think in Java和Gof必定要滚瓜烂熟，不啃上三五遍难得其要。
之后深钻Spring，必有所成。

我刚刚做了三年，当时作为一个初学者，我直接学完了语法以后就直接学习OO了．两年下来，有所小成，但感觉OO还是只抓主了皮毛．
我也觉得banq最了不起的就是能够坚持以OO为技术基础，而我觉得这也正是中国程序员最浮躁的地方．而这种浮躁在.NET领域又特别明显．

组件化开发更加要以OO为基础，组件化最大的目的就是可扩展，可重用，我觉得现代软件就要具备这种特点，否则都不能算是成功的软件．即使你的软件的功能再强大，也只能适应短时间内的使用，如果不具有以上特点，花费大力气的时候还在后面．

我觉得我们在掌握OO理论基础的同时，多多加以实践，
然后学习别人开发出来的轮子，模仿别人的轮子，
最后才能造出新的轮子－－可扩展，可重用的组件．我不仅需要开发框架，还要开发核心业务组件．

的确不能太追求新技术，别人为我为什么到现在都不会ajax，我只是回答：我把所有的精力全部放在和OO有关的技术上了．

恩，要苦练内功

>别人问我为什么到现在都不会ajax，我只是回答：我把所有的精力全部放在和OO有关的技术上了．

非常正确，这是对自己职业负责任，苦练内功的专业方式，软件职业必然走向专业化分工。

本来OO内功是应该在大学基础教育完成的，但是因为大学基础教育方向错误，所以，很多程序员必须在工作中补OO这一课。这是中国软件教育最可悲之处，我等看着不合理就是无能为力啊。

也只有象楼上这样抓住OO基本功，才不会在快速发展的软件行业立于不败之地，因为万宗不离其变。相反，如果不苦练oo基本功，跟在潮流学这个，学那个，反而是捡了芝麻，丢了西瓜，最后总是觉得搞软件很累。

前面楼主提到的CIO素质非常重要，目前我们很多CIO实际是老经验程序员升级做的，这里面问题很大，主要是老程序员的OO基本功往往不足，从而导致他们对组件化构件化对软件开发效率和质量的重要性认识不够，最终在进行软件招标时，对软件架构要求重视不够。

如果我来做CIO，我的做法是：软件招标书至少要指定表现层业务层和持久层相关可选框架，并对业务建模要求对方以UML形式提供。如果这样，国内软件公式一大半要倒闭。然后J道网站被黑。（因为很多程序员的思维学OO可能不合适，但是他的思维钻研黑客程序很合适）。

A good architecture is not only OO.
It is an engineering job.
so for engineer, you must first be clear your target and purpose,then find a optimal not necessary best solution to reach
that goal.
if you encounter problem, then you iterate back to modify your solution to overcome this error or problem.

Therefore,OO is just a fundamental methodology.
To see the problem during a big project building, that is the second level.
Then solve this problem with your oo is the third level.

Your hands-on experience makes more value.
OO will be replaced one day just as if the procedure language.
AS i know, lots of famous labs in USA are doing that.

But the engineer philosophy can never be shaken.
That is why oo is replacing procedure language.because we see the problem in procedure language.

if you see the s

if you see the oo shortage, then it is the fourth level,the toppest one.