程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> J2EE >> 發揚EJB、Spring思想將組件化進行到底

發揚EJB、Spring思想將組件化進行到底

編輯:J2EE

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這幾年冒天下之大不韪,一再堅持重申這個世間最簡單的真理,的確是值得敬佩的。

三、堅持組件化,打造真正的軟件工業


軟件發展到今天,其實應該並且能夠進入到工業時代了。

前面所說的企業軟件危機,既是技術問題,也是產業問題。

今天,地球人的各種產業都是大分工、大合作的工業化產業鏈。生產效率提高了,就業人群也隨之增加。在封建時代,大家都搞小作坊和行會,總覺得如果放開了,分工後大家會沒飯吃。但資本主義的實踐表明,越是分工合作程度高的產業,規模越大。原因很簡單,在生產效率提高的同時,消費被極大地刺激,以至於產業膨脹的速度仍趕不上消費。像現在的汽車,分工合作程度極高,使發達國家的人們買了一輛再買一輛,換了一輛再換一輛,結果是整個汽車產業的繁榮。

我們軟件業(尤以國內為甚)其實也一樣,表面上是沒事可做,事實上是由於軟件業整體的低效率,導致人們用不起軟件,或不敢用軟件。成天忙於低水平重復導致的低水平局部競爭,企業真正關心的很多需求得不到滿足。長久之後企業在信息系統得到的回報太小,自然不願意花錢在信息系統上。

其實大多數開發人員和開發商,都想充分滿足客戶的需求。可惜你幾十號人,打個比方,如果從種橡膠、挖鐵礦、到設計車型,焊接,推銷。什麼都要做,只怕是連小推車也造不出來的。

所以我們一定要分工合作。

現在電腦有了,OS有了,DB有了,編程語言有了,這些最難做的基礎工作外國人都做了。但進入企業級領域仍有無數的工作在等著你。國人在這一點上缺乏合作精神的劣習暴露無遺。明明只是精通業務,非要對設計指手劃腳;不過是分析專家,非要對不熟的技術挑三撿四;明明可以沿用原系統的精華部分,非要替換以示高明;更有不懂事的毛孩子,自以為可以用RAD搞定一切。很多國人的牛人都一種普遍的“超人”意識,老子天下第一,其他人都是垃圾。殊不知軟件業太大太復雜了,再新手的同道,也有很多你不知道的重要知識和奇思妙想;再高的所謂大蝦,也有無數的盲點和愚見。

所以要分工合作,一定要學會尊重他人,實事求是。

至於技術上的問題,其實以筆者愚見。至少spring已經基本上解決了“解耦”的重大難題。大家只要不偷懶,把自已寫的、別人寫的、書上看的,網上下的,好好琢磨透了,以spring這種大體上“無侵入”的框架裝配起來,即可基本上解決組件化的難題。

至於EJB,包括現在相當簡化了的EJB3,由於筆者所知甚淺,不便多述。望高手指點。


每一個程序員,不要想偷懶,努力實踐解耦自己的代碼。

每一個開發商,不要太急功近利,要努力提煉產品的類庫,盡力與其他產商互通互聯。

每一個系統管理員、CIO和企業領導更要謹記:高耦合的系統不能要、無類庫封裝的系統不能要,無測試的系統不能要、無類庫文檔的系統不能要。

這樣才可以杜絕國內急功近利的低水平軟件橫行市場,早日迎來中國軟件的組件化時代,形成健康、有秩、高效的軟件行業。


 

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved