基于J2EE架構(gòu)的企業(yè)應(yīng)用開發(fā)新思維

1、基于J2EE架構(gòu)的企業(yè)應(yīng)用開發(fā)新思維1前言22 Web開發(fā)的困境32.1概述32.2Web系統(tǒng)開發(fā)的復(fù)雜性32.3開發(fā)人員的困境52.4維護(hù)人員的困境62.5科技公司（乙方）的困境72.6客戶(甲方)的困境82.7原因分析103 Web應(yīng)用以誰為中心？瀏覽器？服務(wù)器？113.1B/S的歷史發(fā)展沿革123.2計(jì)算模式歷史143.3初步結(jié)論143.4新模式技術(shù)架構(gòu)143.5新模式技術(shù)范圍163.6新模式下人員分工174 J2EE框架批判184.1關(guān)于J2EE開發(fā)的比喻184.2從C/S開發(fā)模式反思分層的必要性194.3技術(shù)框架上的皮之不存,毛將焉附204.4 J2EE系統(tǒng)架構(gòu)的致命缺陷214.5

2、Hibernate是垃圾224.6為什么J2EE如此低效-用戶無法參與開發(fā)234.7談?wù)剬?duì)web開發(fā)UI基礎(chǔ)架構(gòu)的一些看法275 Web企業(yè)開發(fā)困境原因分析315.1分工過細(xì)315.2技術(shù)路線多頭并進(jìn)325.3開發(fā)維護(hù)復(fù)雜度太高335.4客戶無法參與336解決之道346.1 WebDW產(chǎn)品說明346.1.1 WebDW簡(jiǎn)介346.1.2 WebDW設(shè)計(jì)思路3 WebDW釋義3 WebDW的設(shè)計(jì)理念3數(shù)據(jù)窗口對(duì)象說明376.1.3 界面示意圖（同一個(gè)界面文件，VB，Java，F(xiàn)lex版本不同實(shí)現(xiàn)）386.2其它可行的技術(shù)方向396.2.1跨越語言和

3、平臺(tái)的鴻溝397結(jié)束語401前言在企業(yè)級(jí)的應(yīng)用系統(tǒng)開發(fā)領(lǐng)域，J2EE架構(gòu)現(xiàn)在已經(jīng)被普遍接受了。雖然它并未完全兌現(xiàn)剛剛出現(xiàn)時(shí)的種種美好許諾，跨平臺(tái)，分布式，易于開發(fā)維護(hù)等等，但J2EE的廣泛普及，已經(jīng)是一個(gè)不爭(zhēng)的事實(shí)。雖然J2EE已經(jīng)非常普及，但從技術(shù)上來講，它本身還是存在很多缺陷的，比較突出的缺點(diǎn)，就是開發(fā)效率低，維護(hù)更加復(fù)雜，許多項(xiàng)目組都陷入其中不可自拔。本文將就造成這一現(xiàn)象的原因進(jìn)行初步探討，并在此基礎(chǔ)上提出自己的解決思路。本文討論的范圍僅限于采用B/S開發(fā)企業(yè)的應(yīng)用系統(tǒng)，不涉及網(wǎng)站類型的應(yīng)用開發(fā)。討論的技術(shù)方向，主要針對(duì)J2EE，其余技術(shù)方向不作為重點(diǎn)討論，僅供參考。本文先從Web開發(fā)的

4、現(xiàn)狀困境開始，分析造成目前困境的原因，然后通過回顧B/S技術(shù)架構(gòu)的演化，以及對(duì)比C/S和B/S的開發(fā)模式的差異，提出一套新的開發(fā)解決思路，最后介紹WebDW系列產(chǎn)品的設(shè)計(jì)目的和簡(jiǎn)單功能，再以此為基礎(chǔ)來進(jìn)行擴(kuò)展討論。2 Web開發(fā)的困境2.1概述說明：Web應(yīng)用系統(tǒng)的開發(fā)，像一座大山一樣，把所有的人都?jí)嚎辶?。自互?lián)網(wǎng)出現(xiàn)以來，企業(yè)應(yīng)用系統(tǒng)的架構(gòu)發(fā)生了很大的變化，C/S架構(gòu)被廢棄，B/S成為絕對(duì)的主流。但B/S架構(gòu)本身，要比C/S復(fù)雜的多，加上新技術(shù)層出不窮，整個(gè)行業(yè)都處于巨大的困境之中。Web應(yīng)用系統(tǒng)的開發(fā)，就像一座大山一樣，把所有的人，無論是甲方還是乙方，無論是開發(fā)人員，維護(hù)人員還是系統(tǒng)用戶，

5、都被累垮了。2.2Web系統(tǒng)開發(fā)的復(fù)雜性B/S系統(tǒng)本身的架構(gòu)設(shè)計(jì)，要比C/S系統(tǒng)復(fù)雜很多，在C/S架構(gòu)中，一般是兩層結(jié)構(gòu)。如下圖。一般在這種架構(gòu)中，服務(wù)器是一個(gè)數(shù)據(jù)庫服務(wù)器，只負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和讀取訪問支持；前臺(tái)程序采用 VB，PB，Delphi 等圖形開發(fā)工具來開發(fā)，通過網(wǎng)絡(luò)直接連接到后臺(tái)的數(shù)據(jù)庫服務(wù)器，通過發(fā)送SQL 命令來實(shí)現(xiàn)數(shù)據(jù)庫的訪問。這種開發(fā)環(huán)境下可以使用圖形化的控件來搭建用戶界面，用戶的交互性比較好。缺點(diǎn)在于應(yīng)用程序發(fā)布在客戶端，如果客戶機(jī)數(shù)量很多的話，客戶機(jī)程序的安裝，升級(jí)都比較困難。而在B/S結(jié)構(gòu)中，涉及到了多種服務(wù)器類型，Web服務(wù)器，App服務(wù)器，DB服務(wù)器。如下圖。在B/

6、S系統(tǒng)中，用戶通過客戶機(jī)上的瀏覽器來訪問后臺(tái)的Web服務(wù)器，Web服務(wù)器再把相應(yīng)的請(qǐng)求轉(zhuǎn)發(fā)給應(yīng)用服務(wù)器來處理，應(yīng)用服務(wù)器再將其中的數(shù)據(jù)訪問請(qǐng)求轉(zhuǎn)發(fā)給數(shù)據(jù)庫服務(wù)器進(jìn)行處理。在C/S系統(tǒng)中，應(yīng)用系統(tǒng)或者應(yīng)用程序本身是一個(gè)完整的，獨(dú)立的整體，一般采用一種開發(fā)語言來開發(fā)即可，這種開發(fā)語言不僅負(fù)責(zé)用戶界面，也負(fù)責(zé)業(yè)務(wù)邏輯控制，以及數(shù)據(jù)訪問請(qǐng)求的生成發(fā)送，主要的開發(fā)和執(zhí)行工作是在客戶機(jī)上完成的。而在B/S系統(tǒng)中，整個(gè)系統(tǒng)的架構(gòu)要復(fù)雜的多。首先，客戶機(jī)上只有一個(gè)通用的瀏覽器，用戶操作界面是通過Web服務(wù)器返回的HTML語言來進(jìn)行描述的，如果需要一些動(dòng)態(tài)特征，則不得不通過在HTML頁面中嵌入JavaScrip

7、t來實(shí)現(xiàn)。在應(yīng)用系統(tǒng)中，大量的頁面是動(dòng)態(tài)，而非靜態(tài)頁面，因此必須在應(yīng)用服務(wù)器上完成動(dòng)態(tài)頁面到靜態(tài)HTML的轉(zhuǎn)換工作。如果動(dòng)態(tài)頁面中包含數(shù)據(jù)訪問請(qǐng)求，則又必須訪問后臺(tái)的數(shù)據(jù)庫服務(wù)器來協(xié)助完成此項(xiàng)工作。以J2EE標(biāo)準(zhǔn)流程為例，當(dāng)用戶在瀏覽器上輸入一個(gè)地址，或者URL以后，這個(gè)URL首先傳遞給Web服務(wù)器，然后再轉(zhuǎn)發(fā)給App服務(wù)器來解釋執(zhí)行。假如請(qǐng)求是一個(gè)jsp頁面，應(yīng)用服務(wù)器首先讀取這個(gè)文件，然后把它翻譯成一個(gè)java文件，再編譯成一個(gè)class文件，再解釋執(zhí)行這個(gè)class文件，如果需要再訪問后臺(tái)數(shù)據(jù)庫，最后產(chǎn)生一個(gè)HTML格式的輸出文件流，返回給Web服務(wù)器，再返回給客戶機(jī)瀏覽器解釋成一個(gè)界面

8、。與C/S開發(fā)的一種語言包打天下不同，B/S系統(tǒng)的開發(fā)需要在多個(gè)層次上進(jìn)行編程開發(fā)：瀏覽器中，用HTML和JavaScript編程；應(yīng)用服務(wù)器上，用Java或者.net之類編程，數(shù)據(jù)庫服務(wù)器上用SQL語句編程。在C/S開發(fā)中，最終的產(chǎn)品是一個(gè)Exe文件；而B/S開發(fā)中，最終的產(chǎn)品是一個(gè)網(wǎng)站，里面包含成千上萬個(gè)文件，而且是各種不同類型的文件：HTML,圖片，JSP, Java, Class, XML等等。在Web開發(fā)中，人們?yōu)榱撕?jiǎn)化開發(fā)過程，提高效率，陸續(xù)發(fā)明了很多新技術(shù)，在頁面開發(fā)上，基于JavaScript本身，發(fā)明了如prototype, jQuery, Ajax等框架；基于java技術(shù)，

9、發(fā)明了J2EE架構(gòu)，基于J2EE架構(gòu)，又發(fā)明了Struts, WebWork, Spring, Hibernate ,Itabtis等無數(shù)的框架產(chǎn)品。結(jié)果在試圖解決問題的同時(shí)，這些產(chǎn)品本身又造成了新的問題。相對(duì)于C/S開發(fā)的單一開發(fā)工具開發(fā)，B/S開發(fā)要涉及到很多工具，語言和框架，這些工具，語言和框架，都是為了解決某一問題而設(shè)計(jì)的，而開發(fā)人員必須把這些目的不同的東西整合起來，才能搭建出一個(gè)整體的系統(tǒng)。B/S的復(fù)雜度，很大程度上是由于涉及的技術(shù)面太多，太多的產(chǎn)品，太多的技術(shù)，太多的框架，這樣不僅增加了學(xué)習(xí)的難度，增加了學(xué)習(xí)技術(shù)的成本，而且也增加了系統(tǒng)運(yùn)行維護(hù)的成本，最終提高了整個(gè)系統(tǒng)的開發(fā)，運(yùn)營(yíng)

10、成本。這種高昂的成本讓開發(fā)人員，維護(hù)人員，開發(fā)公司，和甲方都陷入了困境之中，大家在這一困境中掙扎，不能自拔。2.3開發(fā)人員的困境在B/S系統(tǒng)的開發(fā)中，開發(fā)人員是最辛苦的一類人。用戶的所有需求，都需要一行一行編寫代碼來實(shí)現(xiàn)，項(xiàng)目時(shí)間緊，加班加點(diǎn)干，最苦惱的是，要完成一個(gè)基本的功能，需要學(xué)習(xí)一大堆東西才能實(shí)現(xiàn)。HTML, JavaScript, Ajax, Jsp, Servlet, EJB, Jdbc, Struts,Spring ,Hibernate,光是技術(shù)名詞，恐怕一張紙都列不完。開發(fā)人員面臨的困境，就是技術(shù)本身在快速演化發(fā)展，不時(shí)有新名詞，新概念出現(xiàn)，同時(shí)現(xiàn)有的技術(shù)也在快速演化之中，真是

11、生也有涯，而知也無涯，感覺象夸父追日一樣，每日不停的奔跑追趕，何日才是盡頭啊。另外一個(gè)頭疼的事情，就是技術(shù)架構(gòu)的變化性，今天一個(gè)語言，明天一個(gè)語言，一旦底層的平臺(tái)變了，自己費(fèi)勁力氣學(xué)會(huì)的東西就一文不值了，年齡一天一天大了，那里有那么多的精力老追趕新技術(shù)呢，于是很多人轉(zhuǎn)行離開了。但仔細(xì)想一想，所有這些架構(gòu)，這些技術(shù)，真的那么必要嗎？為什么一定要忙于學(xué)習(xí)新的技術(shù)，而不是把精力用在用好現(xiàn)有的技術(shù)上呢？為什么一定要受限于某種具體的語言和技術(shù)，而不是采用跨語言的解決方案呢？為什么一出現(xiàn)新的技術(shù)，就把原來的代碼全部推翻重寫呢？為什么要用這么復(fù)雜的架構(gòu)來實(shí)現(xiàn)原來一種語言就能實(shí)現(xiàn)的簡(jiǎn)單功能呢？譬如，以非常流行

12、的Hibernate來舉例說明，Hibernate的設(shè)計(jì)目的，是簡(jiǎn)化ORM過程，使得數(shù)據(jù)庫的數(shù)據(jù)表可以容易的映射成一個(gè)Java對(duì)象。但問題是，為什么一定要把數(shù)據(jù)表映射成一個(gè)Java對(duì)象呢？如果這種映射本身就不是必須的，那么Hibernate試圖解決的問題，原本就是一個(gè)不存在的問題，那么這個(gè)產(chǎn)品的價(jià)值又何在呢？以我的觀點(diǎn)，Java世界里面這么多框架，產(chǎn)品，語言，很多都是這樣的思路，不是在試圖解決問題，而是在不斷的創(chuàng)造新的問題出來。開發(fā)中用的產(chǎn)品，技術(shù)越多，系統(tǒng)就越復(fù)雜，光是學(xué)習(xí)這些技術(shù)，框架怎么使用，就把開發(fā)人員的時(shí)間和精力耗去大半，而究竟應(yīng)該怎樣來設(shè)計(jì)實(shí)現(xiàn)系統(tǒng)，已經(jīng)沒有人考慮了。時(shí)間和精力被無

13、謂的消耗掉了。這才是開發(fā)人員最大的悲哀所在。Web開發(fā)壓垮的第一批人，是開發(fā)人員。壓垮他們的，是系統(tǒng)的復(fù)雜性。2.4維護(hù)人員的困境終于，在多次延期，多次修改，無數(shù)次補(bǔ)丁以后，系統(tǒng)終于上線了?，F(xiàn)在輪到維護(hù)人員來面對(duì)這個(gè)龐然大物的系統(tǒng)了。系統(tǒng)維護(hù)人員，對(duì)自己的工作，有一個(gè)形象的，不太雅觀的比喻：擦屁股。系統(tǒng)本身開發(fā)起來就復(fù)雜，使用起來也復(fù)雜，再加上開發(fā)過程中隱藏的錯(cuò)誤，行業(yè)術(shù)語叫Bug，維護(hù)人員的電話一直沒有停過，除了操作指導(dǎo)，就是錯(cuò)誤報(bào)告，再加上誤操作以后直接在后臺(tái)數(shù)據(jù)庫里面改數(shù)據(jù)，反正事情又多又雜，整天忙得不亦樂乎。如果是開發(fā)人員自己來做維護(hù)，相對(duì)還好一點(diǎn)，至少里面是怎么回事情，大概知道個(gè)差不

14、多，有了問題，小修小補(bǔ)打打補(bǔ)丁，雖然累點(diǎn)，總還是有希望的；如果不是自己開發(fā)的，要來做維護(hù)，那就要了老命了，要文檔沒文檔，要注釋沒注釋，還要面對(duì)同樣多的技術(shù)架構(gòu)，語言和技術(shù)平臺(tái)，用維護(hù)人員的話說，就是如履薄冰，如臨深淵，每天都在祈禱，這個(gè)系統(tǒng)別出問題。從表面上看，是開發(fā)人員和維護(hù)人員之間的矛盾；從本質(zhì)上看，是系統(tǒng)復(fù)雜度的矛盾。如果一個(gè)系統(tǒng)開發(fā)的很復(fù)雜，那么它本身就很難維護(hù)，即使勉強(qiáng)維護(hù)，維護(hù)的成本也很高。如果你在系統(tǒng)里面用了10項(xiàng)技術(shù)，那么維護(hù)人員就必須學(xué)習(xí)10項(xiàng)技術(shù)才能進(jìn)行維護(hù)；如果你在系統(tǒng)了寫了10萬行代碼，那么維護(hù)人員就必須面對(duì)10萬行代碼。當(dāng)維護(hù)人員覺得系統(tǒng)已經(jīng)無法支持下去時(shí)，他們會(huì)一走

15、了之。而新來的人對(duì)于這個(gè)系統(tǒng)，工作的難度只有更高，更加難以勝任。當(dāng)一個(gè)系統(tǒng)無法維持正常的維護(hù)時(shí)，它的壽命也就到了。這時(shí)就會(huì)把它推掉，重新開始一個(gè)新的系統(tǒng)開發(fā)。不幸的是，新的系統(tǒng)一般來說會(huì)重復(fù)舊系統(tǒng)已經(jīng)走過的路線，開發(fā)的更加復(fù)雜，更加難以維護(hù)，最后再次陷入無法維護(hù)的境界。為什么系統(tǒng)變得難以維護(hù)，因?yàn)橄到y(tǒng)太復(fù)雜；為什么維護(hù)人員無能為力，因?yàn)橄到y(tǒng)太復(fù)雜；為什么維護(hù)成本居高不下，因?yàn)橄到y(tǒng)太復(fù)雜；Web系統(tǒng)壓垮的第二批人，是系統(tǒng)的維護(hù)人員，壓垮他們的，還是系統(tǒng)的復(fù)雜性。2.5科技公司（乙方）的困境和對(duì)個(gè)人的收益不同，系統(tǒng)復(fù)雜性，帶給科技公司的，既有收益，也有風(fēng)險(xiǎn)。系統(tǒng)復(fù)雜度的收益，就是客觀上的跑馬圈地，

16、一件事情簡(jiǎn)單了，能做的人就多，競(jìng)爭(zhēng)就激烈，最后就不好賺錢。CPU不是誰都能設(shè)計(jì)的，所以Intel發(fā)了；OS不是誰都能開發(fā)的，所以MS發(fā)了。把Web系統(tǒng)搞得很復(fù)雜，就會(huì)人為提高它的門檻，能做的公司少了，競(jìng)爭(zhēng)就會(huì)少很多。早期的C/S階段，把整個(gè)MIS系統(tǒng)搞得很簡(jiǎn)單，開發(fā)門檻太低，于是有一大堆的公司來做，最后大家都難以生存下去，現(xiàn)在的外包公司，也不需要公司有啥技術(shù)積累，于是有一大堆公司一起做，最后大家都掙不了錢。從這一方面來說，系統(tǒng)搞的復(fù)雜一些，對(duì)科技公司來說，客觀上是有一定好處的。最大的好處，是提供這種復(fù)雜性的基礎(chǔ)設(shè)備的公司，例如Oracle, BEA, SUN, HP這些。以O(shè)racle為例，每

17、升級(jí)一個(gè)版本，就可以訪問更快，存儲(chǔ)更多，也就能賣更多錢。但問題是：究竟有什么必要在系統(tǒng)中存儲(chǔ)那么多的信息呢？這些信息真的增長(zhǎng)那么快嗎？還是垃圾增長(zhǎng)快呢？基于這個(gè)原因，所有的基礎(chǔ)設(shè)備提供商，都在不遺余力地推進(jìn)系統(tǒng)的復(fù)雜性，今天一個(gè)標(biāo)準(zhǔn)，明天一個(gè)標(biāo)準(zhǔn)，如果有現(xiàn)成的標(biāo)準(zhǔn)，就把這個(gè)標(biāo)準(zhǔn)不斷升級(jí)，讓你跟著跑，整天疲于奔命，永遠(yuǎn)處在追趕之中。最典型的例子就是Microsoft了，無論操作系統(tǒng)也好，Office也好，IE也好，反正三年必升級(jí)，強(qiáng)制性讓你報(bào)廢現(xiàn)在的東西。這就是基礎(chǔ)設(shè)備提供商的生命所在，不斷增加系統(tǒng)的復(fù)雜性。對(duì)于具體的開發(fā)公司來說，系統(tǒng)的復(fù)雜性就是可怕的敵人了。系統(tǒng)越復(fù)雜，開發(fā)的成本就越高，維護(hù)

18、成本也越高，如果客戶不為這些來買單的話，開發(fā)公司就會(huì)做一個(gè)項(xiàng)目，賠一個(gè)項(xiàng)目，最后把公司賠光，關(guān)門拉倒。在人月神話中，講述了恐龍?jiān)谀嗾又袙暝?，掙扎的越厲害，險(xiǎn)的越深；現(xiàn)在很多的開發(fā)公司也是一樣，險(xiǎn)在項(xiàng)目之中不能自拔，活兒越干越多，不知何日才是頭，最后一算賬，還不能掙錢。對(duì)于公司來講，人力成本居高不下，所有人員被困在一個(gè)個(gè)項(xiàng)目中掙扎，公司永遠(yuǎn)長(zhǎng)不大，變不強(qiáng)。很多人會(huì)講這個(gè)現(xiàn)象歸咎于大環(huán)境和客戶的不成熟。也許他們是對(duì)的。但從深層次看，還是系統(tǒng)的復(fù)雜度問題，系統(tǒng)太復(fù)雜，以至于把開發(fā)公司的人力，物力，財(cái)力都消耗殆盡，根本無力發(fā)展。在一個(gè)復(fù)雜度無法控制的狀態(tài)下，公司只能是疲于奔命，隨波逐流。Web系統(tǒng)壓垮

19、的第三批人，是一個(gè)個(gè)開發(fā)公司，壓垮他們的，還是系統(tǒng)的復(fù)雜性。2.6客戶(甲方)的困境Web系統(tǒng)的復(fù)雜性，依次打垮了開發(fā)人員，維護(hù)人員和開發(fā)公司，現(xiàn)在輪到甲方來承擔(dān)它的后果了。甲方的科技人員對(duì)于系統(tǒng)的復(fù)雜性，往往缺乏先見之明。所有的招標(biāo)文件中，一律指出要保證技術(shù)的先進(jìn)性，素不知，所謂的先進(jìn)性，往往也意味著新技術(shù)，對(duì)于整個(gè)系統(tǒng)而言，往往是增加其復(fù)雜性，而不是減少其復(fù)雜性。國內(nèi)的甲方對(duì)于項(xiàng)目開發(fā)往往有個(gè)誤區(qū)，喜歡按照人員的工作量，通常是人月來估算項(xiàng)目的費(fèi)用，預(yù)算和成本。其實(shí)這是很不取的。很多時(shí)候只是盲目的要求增加人手，卻不考慮到底有沒有這么多工作需要人來做，或者做這件事情的時(shí)機(jī)是否成熟，是否合適。在

20、按人頭計(jì)算費(fèi)用的模式下，開發(fā)公司傾向于增加人手來提高整個(gè)項(xiàng)目的費(fèi)用計(jì)算，而且最好是增加低成本的新手來做項(xiàng)目，這樣做的結(jié)果就是整個(gè)項(xiàng)目陷入盲目運(yùn)行的狀態(tài)，所有的人都在忙，但不知道在忙啥，整體作的是無用功。很多時(shí)候把甲方的人員也拉了進(jìn)來，包括業(yè)務(wù)人員和科技人員，大家一起瞎忙，一起浪費(fèi)時(shí)間做無用功。項(xiàng)目開發(fā)的種種問題，最后的惡劣后果，實(shí)際上都是由甲方來承擔(dān)的。甲方既是項(xiàng)目的投資人，也是最終的使用者，如果項(xiàng)目不能達(dá)到目標(biāo)，最終買單的是甲方。項(xiàng)目的過程管理，時(shí)間管理這些都先不談，單獨(dú)談?wù)勴?xiàng)目的復(fù)雜性對(duì)甲方的長(zhǎng)遠(yuǎn)影響。首先是開發(fā)成本的失控，項(xiàng)目越復(fù)雜，開發(fā)的成本也越高，這些不必要的成本，或者說資源的浪費(fèi)，

21、最終是由甲方來買單的，開發(fā)公司最多不干了退出，甲方卻退無可退，硬著頭皮也要把項(xiàng)目做完。其次是項(xiàng)目最終難以維護(hù)，正如上面所談到的，系統(tǒng)越復(fù)雜，以后的維護(hù)就越困難。而更加要命的是，一個(gè)企業(yè)內(nèi)部會(huì)有多個(gè)系統(tǒng)，這些系統(tǒng)分別由不同的開發(fā)商在不同時(shí)間按照不同的技術(shù)來開發(fā)，有的甚至已經(jīng)換手幾次。而甲方的科技部門要同時(shí)維護(hù)這樣并行的多個(gè)系統(tǒng)，再考慮各個(gè)系統(tǒng)之間的交互關(guān)系，最后的結(jié)果就是焦頭爛額，忙得不可開交。從整體上來看，甲方對(duì)于信息技術(shù)可以說是又愛又恨，一方面，現(xiàn)在的企業(yè)運(yùn)行離不開這些系統(tǒng)，另一方面，這些系統(tǒng)在帶來便利的同時(shí)，又帶來了無窮無盡的麻煩。每個(gè)系統(tǒng)的搭建費(fèi)時(shí)費(fèi)力，最后用不了幾年就漏洞百出，不得不推

22、倒重來。整個(gè)系統(tǒng)的建設(shè)在不斷重復(fù)這一故事，直到下一個(gè)輪回開始。有的甲方是家大業(yè)大，浪費(fèi)點(diǎn)沒啥，他們可能不太在乎系統(tǒng)建設(shè)時(shí)浪費(fèi)的一點(diǎn)點(diǎn)資金，但對(duì)于系統(tǒng)運(yùn)行帶來的煩惱也是無可奈何。而有的甲方本身的底子就比較薄一些，這些系統(tǒng)建設(shè)上的浪費(fèi)和失敗就可能直接導(dǎo)致企業(yè)的巨大損失。行內(nèi)有句名言，不上ERP是等死，上ERP是找死。說的就是這種現(xiàn)象。順便說一下前幾年的ERP熱，以后隨后對(duì)ERP的全面質(zhì)疑。盡管角度不同，論述的結(jié)論也更不相同，我對(duì)這方面沒有研究，不好妄論。但無論那種觀點(diǎn)，都承認(rèn)ERP是一個(gè)非常復(fù)雜的系統(tǒng)，而無論開發(fā)，實(shí)施，維護(hù)一個(gè)復(fù)雜的系統(tǒng)，其成本都是非常高昂的，無論那個(gè)環(huán)節(jié)跟不上，都會(huì)帶來項(xiàng)目的失

23、敗和停滯。項(xiàng)目的復(fù)雜性，如果沒有能夠壓垮甲方的話，甲方就會(huì)繼續(xù)和項(xiàng)目的復(fù)雜性進(jìn)行持續(xù)斗爭(zhēng)。如果壓力過大的話，甲方就會(huì)發(fā)現(xiàn)，自己本來是一個(gè)業(yè)務(wù)性的公司，最后卻不明不白變成了一個(gè)IT相關(guān)的公司，信息部門最后變成了尾大不掉的一個(gè)部門。甲方的困境，簡(jiǎn)單來說在于成本的投入和收益不成比例，由于系統(tǒng)的復(fù)雜性不斷增加，甲方的投資被不斷消耗在調(diào)合系統(tǒng)的復(fù)雜性上，而不能用在更有效益的地方。現(xiàn)在的項(xiàng)目開發(fā)現(xiàn)狀，使得很多甲方變成了一朝被蛇咬，十年怕井繩，對(duì)于后續(xù)項(xiàng)目的開發(fā)，早已失去了往日的激情和動(dòng)力。根本的矛盾，仍然在復(fù)雜度上，只有降低項(xiàng)目的復(fù)雜度，才是解決問題的根本途徑。2.7原因分析雖然在人月神話中，布魯克斯已經(jīng)

24、指出：軟件的復(fù)雜性是它的本質(zhì)特性之一，但在實(shí)際工作中，人們往往容易忘記這一點(diǎn)。軟件的復(fù)雜性來源很多，但B/S系統(tǒng)的復(fù)雜性，又對(duì)C/S時(shí)代更有進(jìn)步，尤其是J2EE的項(xiàng)目開發(fā)，其復(fù)雜性在不斷增加。具體原因很多，但涉及的技術(shù)太多，是重要原因。目前，B/S系統(tǒng)開發(fā)涉及的技術(shù)面太多，在界面展示，業(yè)務(wù)流程，數(shù)據(jù)操作等多方面，目前一般采用不同的技術(shù)方案，不同的框架，不同的產(chǎn)品來處理和實(shí)現(xiàn)。這些產(chǎn)品本身都是相對(duì)獨(dú)立的，都構(gòu)成一個(gè)自己的知識(shí)體系，而要把這些不同范疇的技術(shù)整合起來，使之成為一個(gè)統(tǒng)一的整體，光在技術(shù)層次上，就構(gòu)成了一個(gè)非常復(fù)雜的系統(tǒng)。 以我自己親身經(jīng)歷的一個(gè)項(xiàng)目為例，在這個(gè)項(xiàng)目中，數(shù)據(jù)庫用的是Ora

25、cle，應(yīng)用服務(wù)器用的是Websphere，非機(jī)構(gòu)化存儲(chǔ)用的是FileNet，數(shù)據(jù)加載用的是BO的Data Integration，報(bào)表工具用的是Congo，身份認(rèn)證用的是Troliv 和 Microsoft的Active Directory，還有自己編制的郵件監(jiān)控服務(wù)，林林總總，一個(gè)項(xiàng)目用了不下7種產(chǎn)品，其中任何一個(gè)產(chǎn)品都需要依賴專業(yè)知識(shí)才能正常使用，更別提把這些產(chǎn)品混合起來搭建成一個(gè)系統(tǒng)了。一個(gè)系統(tǒng)涉及的內(nèi)容越多，也就意味著出現(xiàn)錯(cuò)誤的幾率越大，這樣一個(gè)系統(tǒng)也就更加不穩(wěn)定。而系統(tǒng)的價(jià)值，就在于它的穩(wěn)定性，一個(gè)沒有起碼穩(wěn)定性的系統(tǒng)，是不會(huì)產(chǎn)生價(jià)值的。在傳統(tǒng)的J2EE框架內(nèi)，應(yīng)用開發(fā)已經(jīng)太過復(fù)雜

26、，變得臃腫龐大，這一點(diǎn)業(yè)內(nèi)已有定論。正是基于這個(gè)考慮，近年來出現(xiàn)了一些試圖簡(jiǎn)化這一過程的產(chǎn)品和框架，例如Spring, Hibernate，都是這種思路的產(chǎn)物。但不幸的是，諸如Spring, Hibernate這樣的產(chǎn)品，在解決某一問題的同時(shí)，又往往帶來更多的問題，只是用一個(gè)問題代替了另一個(gè)問題，從整個(gè)系統(tǒng)的角度來看，整體的復(fù)雜度不僅沒有減少，反而有逐步增加的勢(shì)頭。開發(fā)人員現(xiàn)在需要學(xué)習(xí)的東西，不是更少了，而是更多了；工作不僅變得輕松，反而更加復(fù)雜，更加混亂，也更加沒有生產(chǎn)力了。3 Web應(yīng)用以誰為中心？瀏覽器？服務(wù)器？企業(yè)Web應(yīng)用，指的是企業(yè)內(nèi)部使用B/S架構(gòu)搭建的企業(yè)信息系統(tǒng)，用戶一般局限

27、在企業(yè)內(nèi)部，為了適應(yīng)企業(yè)某個(gè)業(yè)務(wù)流程而設(shè)計(jì)開發(fā)使用的系統(tǒng)。出于跨地域部署升級(jí)的考慮，一般采用B/S模式進(jìn)行開發(fā)，避免在每個(gè)客戶端安裝配置的麻煩。一般情況下，前臺(tái)瀏覽器特指IE瀏覽器，前臺(tái)操作系統(tǒng)選擇Windows操作系統(tǒng)。非Windows操作系統(tǒng)的客戶機(jī)與非IE的瀏覽器不在本文討論范圍之內(nèi)。本文主要討論以J2ee架構(gòu)為基礎(chǔ)的Web應(yīng)用，其他架構(gòu)的暫不討論。IE瀏覽器WebApp服務(wù)器DB服務(wù)器在這種情況下，數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫上，一般沒有多大疑問。而附件文件一般存放在Web服務(wù)器上，也沒有太大疑問。最主要的問題是：整個(gè)應(yīng)用應(yīng)該是以瀏覽器為中心，還是以服務(wù)器為中心？在J2ee出現(xiàn)的早期，這一問題是不

28、存在的，當(dāng)時(shí)的瀏覽器，基本上可以看成是互聯(lián)網(wǎng)時(shí)代的終端機(jī)。當(dāng)時(shí)的計(jì)算模式，是完全基于后臺(tái)服務(wù)器的計(jì)算。3.1B/S的歷史發(fā)展沿革計(jì)算時(shí)代劃分瀏覽器服務(wù)器總結(jié)史前時(shí)代/靜態(tài)頁面的時(shí)代僅支持Html，只能顯示文本和圖片靜態(tài)文件存儲(chǔ)；靜態(tài)時(shí)代，沒有動(dòng)態(tài)內(nèi)容史前時(shí)代/CGI動(dòng)態(tài)頁面時(shí)代僅支持Html利用CGI方式動(dòng)態(tài)生成一個(gè)HTML文件給瀏覽器動(dòng)態(tài)時(shí)代，動(dòng)態(tài)信息由后臺(tái)服務(wù)器計(jì)算產(chǎn)生，與前臺(tái)無關(guān)Java AppletActiveX控件時(shí)代瀏覽器里面可以嵌入其他應(yīng)用程序來顯示動(dòng)態(tài)內(nèi)容JavaScript出現(xiàn)瀏覽器第一次擁有了計(jì)算能力，把計(jì)算資源從服務(wù)器上解放了出來J2EE時(shí)代應(yīng)用服務(wù)器時(shí)代Applet被廢

29、棄Javascript開始發(fā)展后臺(tái)采用J2EE架構(gòu)，JSP等多種方式生成動(dòng)態(tài)頁面J2EE架構(gòu)把系統(tǒng)的重心牢牢地綁定在后臺(tái)的應(yīng)用服務(wù)器上后J2EE時(shí)代開源運(yùn)動(dòng)時(shí)代Javascript開始大發(fā)展，Ajax出現(xiàn)J2EE開始走向沒落，為彌補(bǔ)其缺陷，開源框架出現(xiàn)。SSH大行其道應(yīng)用服務(wù)器不堪重負(fù)，輕量級(jí)別的框架開始出現(xiàn)作為替代品?？蛻舳送跽邭w來Ajax時(shí)代Ajax風(fēng)靡一時(shí)Javascript框架大量出現(xiàn)。Flex/SL/ExtJs各行其道服務(wù)器端處于停滯狀態(tài)，JSF曇花一現(xiàn)后臺(tái)的問題已經(jīng)基本解決，現(xiàn)在關(guān)注的重點(diǎn)又轉(zhuǎn)向前臺(tái)，解決用戶界面和友好性問題。未來自定義瀏覽器時(shí)代瀏覽器中的瀏覽器Flex大發(fā)展SL大

30、發(fā)展自定義ActiveX 大發(fā)展JavaScript逐漸衰退服務(wù)器進(jìn)一步弱化，弱化為為前臺(tái)提供必要服務(wù)，應(yīng)用中心轉(zhuǎn)移通過Ajax技術(shù),利用DWR等工具。瀏覽器終于把握了應(yīng)用的全面主動(dòng)權(quán)。從整體上來看，整個(gè)應(yīng)用架構(gòu)的發(fā)展，體現(xiàn)了從理想的B/S架構(gòu)到C/S架構(gòu)的回歸過程。3.2計(jì)算模式歷史字符終端/啞終端/主機(jī) 時(shí)代Unix圖形化終端/客戶機(jī)/服務(wù)器 時(shí)代Apple, DOS,Windows,Oracle啞瀏覽器時(shí)代Netscape/ ApacheApplet時(shí)代AppletJ2EE時(shí)代WebLogic/Websphere/JBoss后J2EE時(shí)代/開源框架時(shí)代Struts/Spring/Hibe

31、rnateIBMApple / MSOracle/SybaseNetScapeSun / JavaBEA/ApacheIBMRIA時(shí)代Flex / SlightLight / ExtJSAdobe / MSJavaScript3.3初步結(jié)論核心問題在與瀏覽器和服務(wù)器的合理分工。把所有問題壓在瀏覽器或者都?jí)涸诜?wù)器并不合適。3.4新模式技術(shù)架構(gòu)按照上面的演化過程，可以提出一種全新的，以瀏覽器為中心的技術(shù)架構(gòu)模式。序號(hào)通用功能瀏覽器功能服務(wù)器功能備注1用戶界面渲染渲染Html為標(biāo)準(zhǔn)用戶界面；可能內(nèi)嵌一個(gè)自定義的界面渲染工具；以純靜態(tài)HTML頁面為主少數(shù)以JSP形式提供，動(dòng)態(tài)生成以瀏覽器為主，服務(wù)器

32、為輔助功能。訪問采用標(biāo)準(zhǔn)HTTP協(xié)議進(jìn)行2動(dòng)態(tài)數(shù)據(jù)訪問(數(shù)據(jù)庫讀取/存儲(chǔ))調(diào)用后臺(tái)功能接口，得到標(biāo)準(zhǔn)格式的數(shù)據(jù)包信息；并對(duì)這些數(shù)據(jù)進(jìn)行渲染提供標(biāo)準(zhǔn)訪問接口，供瀏覽器進(jìn)行調(diào)用前臺(tái)發(fā)送調(diào)用要求，后臺(tái)響應(yīng)返回結(jié)果。調(diào)用方式可采用DWR模式進(jìn)行3界面跳轉(zhuǎn)瀏覽器根據(jù)本身狀態(tài)變化主動(dòng)跳轉(zhuǎn)存儲(chǔ)頁面跳轉(zhuǎn)規(guī)則，將此規(guī)則以標(biāo)準(zhǔn)方式發(fā)送給瀏覽器4SQL生成可以在瀏覽器生成可以在服務(wù)器生成兩面都可生成，后臺(tái)生成SQL，前臺(tái)可以看到5業(yè)務(wù)邏輯可以在瀏覽器實(shí)現(xiàn)可以在服務(wù)器實(shí)現(xiàn)如果在后臺(tái)實(shí)現(xiàn)，前臺(tái)通過Ajax或者DWR方式調(diào)用6開發(fā)語言工具JavaScriptExtJsActiveX控件COM調(diào)用Pure Java開發(fā)SS

33、H等開源框架EasyCare開發(fā)平臺(tái)根據(jù)需要選擇7核心問題數(shù)據(jù)交換規(guī)范數(shù)據(jù)交換規(guī)范數(shù)據(jù)交換的標(biāo)準(zhǔn)化是系統(tǒng)框架的核心問題數(shù)據(jù)庫服務(wù)器/ 數(shù)據(jù)信息表應(yīng)用服務(wù)器 / 應(yīng)用標(biāo)準(zhǔn)服務(wù)提供層標(biāo)準(zhǔn)服務(wù)：服務(wù)1，服務(wù)2，服務(wù)3，服務(wù)4，服務(wù)5業(yè)務(wù)管理服務(wù): 服務(wù)1，服務(wù)2，服務(wù)3功能1功能2功能3功能4應(yīng)用系統(tǒng)服務(wù)提供規(guī)范說明定義3.5新模式技術(shù)范圍序號(hào)運(yùn)行點(diǎn)所使用技術(shù)說明1數(shù)據(jù)庫服務(wù)器SQLOracle標(biāo)準(zhǔn)SQL語句在服務(wù)器端編程開發(fā)，創(chuàng)建，維護(hù)數(shù)據(jù)表2應(yīng)用服務(wù)器JavaServletJSP采用標(biāo)準(zhǔn)Java語言，在應(yīng)用服務(wù)器上編寫Servlet，對(duì)外提供標(biāo)準(zhǔn)服務(wù)3瀏覽器HTMLCSS標(biāo)準(zhǔn)的HTML,CSS樣

34、式來實(shí)現(xiàn)渲染，此功能要弱化4瀏覽器JavaScriptExtJSJavaScript調(diào)用Extjs等來實(shí)現(xiàn)數(shù)據(jù)處理，動(dòng)態(tài)界面內(nèi)容的渲染5瀏覽器ActiveXFlex采用插件形式來實(shí)現(xiàn)對(duì)界面動(dòng)態(tài)數(shù)據(jù)的界面渲染6瀏覽器JavaScriptAjaxDWR通過DWR等Ajax技術(shù)實(shí)現(xiàn)前后臺(tái)的功能調(diào)用，后臺(tái)提供數(shù)據(jù)，前臺(tái)負(fù)責(zé)對(duì)返回?cái)?shù)據(jù)的動(dòng)態(tài)界面渲染3.6新模式下人員分工序號(hào)角色技術(shù)特長(zhǎng)說明技術(shù)難度1項(xiàng)目經(jīng)理負(fù)責(zé)項(xiàng)目進(jìn)度管理中級(jí)2架構(gòu)師ALL確定系統(tǒng)技術(shù)架構(gòu)，明確那些技術(shù)可用于此項(xiàng)目，如何使用此技術(shù)中級(jí)3DBA數(shù)據(jù)庫管理數(shù)據(jù)庫規(guī)范設(shè)計(jì)，編寫數(shù)據(jù)字典中級(jí)4后臺(tái)服務(wù)開發(fā)JavaServletJSP利用Java

35、語言，編寫后臺(tái)的通用服務(wù)功能，編寫前后臺(tái)的標(biāo)準(zhǔn)數(shù)據(jù)訪問規(guī)范高級(jí)5前臺(tái)界面開發(fā)人員JavaScriptDWR利用JavaScript,調(diào)用后臺(tái)提供服務(wù)，編寫前臺(tái)的顯示界面，主要語言為JavaScript，可能嵌入其他ActiveX控件，JS控件初級(jí)6前臺(tái)控件開發(fā)人員JavaScriptExtJSActiveXVB,VC利用JavaScript, VB, VC等工具，編寫前臺(tái)通用的頁面級(jí)別的控件。這一控件專注于對(duì)數(shù)據(jù)顯示的界面渲染以及對(duì)數(shù)據(jù)的處理過程，但此過程不涉及與后臺(tái)的數(shù)據(jù)信息交互。高級(jí)7項(xiàng)目秘書Word編寫各種文檔，將原始文檔歸檔，格式化。初級(jí)4 J2EE框架批判這一章節(jié)主要是將以前零星編寫

36、的關(guān)于J2EE框架的一些感想集中起來，文字方面沒有進(jìn)行太多的潤(rùn)色。主題思想是對(duì)流行一時(shí)的J2EE框架進(jìn)行批判。對(duì)J2EE框架進(jìn)行批判的目的，并不是要否認(rèn)其本身的技術(shù)價(jià)值，而是指出單純采用標(biāo)準(zhǔn)的J2EE架構(gòu)開發(fā)，將會(huì)面臨那些問題。4.1關(guān)于J2EE開發(fā)的比喻打個(gè)比方. 現(xiàn)在的j2ee開發(fā),就好象對(duì)面來了一個(gè)人. 最外面穿著一件風(fēng)衣(HTML) 風(fēng)衣里面穿著西裝(Struts) 西裝里面穿著馬甲(Spring) 馬甲里面穿著襯衫(Hibernate) 襯衫的里面才是真實(shí)的人(數(shù)據(jù)庫) 全部衣服都是采用棉布做成的(Java) 每件衣服上都可能有其他配件(第3方庫) 各件衣服之間需要配套使用(版本兼容

37、) 如果你想看到這個(gè)人到底長(zhǎng)啥樣,必須得:先脫一件,再脫一件,再脫一件.最后才能看到最終數(shù)據(jù)庫里面的數(shù)據(jù)是啥樣子. 在很久很久以前,這個(gè)人是不穿衣服的. 你直接可以看到他(SQL語句) 現(xiàn)在不行了,你必須穿越層層衣服來看這個(gè)人. 每件衣服都是不同的廠家做出來的.而且隨時(shí)在改變. （patch包）你必須自己把這些衣服一件一件套上去,祈禱他們大概能夠合身.(版本兼容)4.2從C/S開發(fā)模式反思分層的必要性在今天的Java Web開發(fā)中,各種模式,框架層出不窮,頗有長(zhǎng)江后浪推前浪,前浪死在沙灘上之勢(shì).但這些框架,真的是那么必要的嗎? 回顧十年前,當(dāng)時(shí)只要學(xué)會(huì)一個(gè)開發(fā)工具,VB也好,Delphi也好,

38、PB也好,VC也罷,在一個(gè)開發(fā)環(huán)境里面,所有的應(yīng)用開發(fā)就全部解決了,當(dāng)時(shí)有這些框架嗎?沒有.當(dāng)時(shí)的系統(tǒng)比現(xiàn)在功能簡(jiǎn)單嗎?不簡(jiǎn)單.當(dāng)時(shí)的開發(fā)效率低嗎,不低.由此看來,現(xiàn)在這么風(fēng)光無限的種種框架,也許根本沒有必要存在的必要. 究竟是什么原因,使得人們放棄了已經(jīng)成熟的開發(fā)方式,轉(zhuǎn)向現(xiàn)在這種漏洞百出的開發(fā)模式,動(dòng)不動(dòng)一個(gè)框架,動(dòng)不動(dòng)一個(gè)架構(gòu)的處境呢? 原因很多,廠家的推波助瀾,客戶的隨波逐流,大家一起跟風(fēng)的結(jié)果. 我這里不打算分析那么多原因所在,只是談一談我對(duì)B/S和C/S開發(fā)的一個(gè)看法. 在C/S程序的開發(fā)中,界面,應(yīng)用,數(shù)據(jù)這三者是統(tǒng)一在一起的,當(dāng)你思考一個(gè)問題的時(shí)候,這三者是統(tǒng)一的一個(gè)整體.最典

39、型的設(shè)計(jì)方案,就是所謂的IPO圖型. 某個(gè)業(yè)務(wù)流程,它的輸入是什么,從那張表來,這是I,Input. 它的輸出是什么,到那張表去,這是O,Output 在這個(gè)業(yè)務(wù)過程中具體做那些處理,這是P,Process. 業(yè)務(wù)分析也好,數(shù)據(jù)處理也好,都是具體圍繞這個(gè)IPO來進(jìn)行的,在此基礎(chǔ)上再進(jìn)行數(shù)據(jù)表結(jié)構(gòu)的設(shè)計(jì),算法的具體設(shè)計(jì),再加上用戶界面,程序就開發(fā)完成了. 這樣的一個(gè)程序,它的邏輯,界面,數(shù)據(jù)三者是統(tǒng)一在一起的,理解它的時(shí)候,也是統(tǒng)一在一起理解的. 不幸的是,在B/S目前的開發(fā)過程中,出于進(jìn)化的原因,上述的模式被顛覆,被否認(rèn)了.這里的討論主要是針對(duì)Java的業(yè)務(wù)系統(tǒng)開發(fā),不涉及其他開發(fā)模式. 就拿

40、現(xiàn)在流行一時(shí)的SSH模式來說吧. Struct作為Web層的框架,Spring作為應(yīng)用層的框架,Hibernate作為數(shù)據(jù)持久層的框架. 如果僅從Java開發(fā)的角度來看,可能會(huì)覺得這種分類,分層簡(jiǎn)直是完美無缺的;但如果和C/S的開發(fā)模式進(jìn)行對(duì)比就會(huì)發(fā)現(xiàn),這種強(qiáng)制性的分層,其實(shí)是人為將原來的一件事情,分成三個(gè)層次來解決,然后每個(gè)層次再加上額外的解決方案的一個(gè)解決方案. 或者說,所有這些問題,本來可以根本上就不存在,但你生生制造出這么多問題來,最后再發(fā)明出一個(gè)解決方案來解決這些問題.在解決的過程中帶來的新的問題,于是再發(fā)明一些新的方案來解決這些問題. 以前有個(gè)笑話,說某人找了個(gè)媳婦,在和面,面多了

41、,就加水,一會(huì)兒水多了,就加面,于是乎事情越來越多. 現(xiàn)在的Java Web開發(fā),正走向這樣一條不歸路,發(fā)現(xiàn)一個(gè)問題,就發(fā)明一個(gè)新框架來解決,于是又帶來新的一個(gè)問題,于是又發(fā)明另一個(gè)框架來解決. 現(xiàn)在Java Web開發(fā)的一個(gè)怪現(xiàn)象是,程序的代碼不少,但和業(yè)務(wù)有關(guān)的沒有多少, 相反是框架相關(guān)的層出不窮. 所有這些問題的根源,我看就出在強(qiáng)制性的分層上. 界面層,業(yè)務(wù)邏輯層,數(shù)據(jù)訪問層的劃分并沒有問題,問題在于分層以后,是否一定要把他們拆分到不同的代碼段來實(shí)現(xiàn),是否一定要把這些當(dāng)成完全不同的問題來采用完全不同的藥方來解決. 既然在C/S上這三個(gè)問題可以簡(jiǎn)單來用一個(gè)語言,一個(gè)方案來解決,為啥B/S的

42、開發(fā)一定要分開處理,搞的大家疲勞不堪呢? 4.3技術(shù)框架上的皮之不存,毛將焉附關(guān)于技術(shù),語言上的是是非非,實(shí)在不是一兩句話能夠說清楚的事情. 前兩天在和朋友的交流中,忽然想到這樣一句話:皮之不存,毛將焉附,以此來形容很多技術(shù)的興衰,真是非常貼切. 所有的技術(shù),語言也好,框架也好,其實(shí)都有一個(gè)基本的假設(shè),在討論問題的時(shí)候,往往是在這個(gè)隱函的前提下來討論才得出的結(jié)論,一旦經(jīng)過認(rèn)真考慮,把這個(gè)假設(shè)推翻了,那么整個(gè)技術(shù)的大廈也就轟然倒塌了. 以下舉例說明. 譬如J2EE架構(gòu),在早期推出的時(shí)候,強(qiáng)調(diào)EJB這一組件的功能,其實(shí)隱含了一個(gè)假設(shè):所有的應(yīng)用都需要分布式支持,所以才提出EJB這樣一個(gè)分布式的技術(shù)

43、方案.后來在實(shí)踐中終于發(fā)現(xiàn),絕大部分應(yīng)用都不真正需要分布式支持,于是乎EJB就變成了J2EE中著名的雞肋產(chǎn)品.甚至基于這個(gè)觀點(diǎn),推除了J2EE without ejb這樣的概念出來.此其例一. 譬如JSP技術(shù),按其本名,Java Server Page,就是利用Java語言在后臺(tái)服務(wù)器上,動(dòng)態(tài)生成一個(gè)Page的意思.這里其實(shí)有兩個(gè)隱含的假設(shè),其一,頁面是動(dòng)態(tài)生成,而且是用Java動(dòng)態(tài)生成;其二,頁面是在服務(wù)器上生成,而不是在客戶端生成.在技術(shù)發(fā)展的早期,這一概念確實(shí)風(fēng)靡一時(shí).但在目前的技術(shù)生態(tài)中,增加了Ajax和RIA的概念,在RIA的概念中,頁面完全是可以由客戶端來動(dòng)態(tài)生成的,這種情況下,就

44、把JSP存在的基本假設(shè)推翻了,長(zhǎng)此下去,JSP技術(shù)的立足點(diǎn)就不復(fù)存在了. 再譬如Jsp的tag技術(shù),它的基本假設(shè)是采用JSP技術(shù)來做頁面展示,一旦上面第二條中談到的假設(shè) 被推翻了,jsp的tag技術(shù)也就沒有立足之地了. 譬如Hibernate技術(shù),它的隱含假設(shè),就是對(duì)于數(shù)據(jù)庫的操作,必須通過對(duì)象方式來實(shí)現(xiàn),不能直接編寫SQL語句,一旦這一假設(shè)不存在了,Hibernate的用處也就不存在了. 譬如Spring技術(shù),它的隱含假設(shè),就是所有業(yè)務(wù)邏輯及數(shù)據(jù)處理等等,都集中在服務(wù)器上進(jìn)行,而且這些組件還是經(jīng)常要改變的,所以為了管理方便,給你搞一套IOC的玩藝兒來試圖簡(jiǎn)化它. 但如果這些假設(shè)都不存在了,要

45、Spring干啥用呢? 這樣的例子簡(jiǎn)直舉不勝舉. 大家在瘋狂的討論技術(shù)的種種優(yōu)勢(shì)和缺點(diǎn),但是在討論這些問題之前,請(qǐng)先明確一下,所有這些討論,它的假設(shè)是什么,它的前提是什么.4.4 J2EE系統(tǒng)架構(gòu)的致命缺陷關(guān)于j2ee系統(tǒng)的是是非非,已經(jīng)有無數(shù)的口水了, 實(shí)在沒有必要增加更多的口水. 昨天忽然想到,這個(gè)系統(tǒng)的整體架構(gòu),其實(shí)有一個(gè)很大的缺陷. 這個(gè)缺陷就是,j2ee的架構(gòu)中,對(duì)于最終的客戶端,是假設(shè)作為啞終端來存在的,除了顯示一個(gè)界面以外,基本上啥也不能干. 這是整個(gè)j2ee架構(gòu)最基本的理論基礎(chǔ).正是基于此,才有了各種各樣的細(xì)分技術(shù)方案,組合起來形成一個(gè)j2ee的理論體系. 后來的javascr

46、ipt其實(shí)是不包括在這個(gè)體系之內(nèi)的,而且隨著在客戶端開發(fā)的增加,再逐漸增加了各種各樣的框架進(jìn)去,其實(shí)是對(duì)原來的那個(gè)基本假設(shè)的一步一步否定. 如果客戶端不再是一個(gè)啞終端的話,那么整個(gè)j2ee體系存在的合理性就不復(fù)存在了. 所以java這個(gè)陣營(yíng)的,都在拼命在服務(wù)器方面下功夫,對(duì)客戶機(jī)盡量不動(dòng).而這造成了很多的無用功. AJAX出現(xiàn)以后,事情逐漸發(fā)生變化,客戶端的開發(fā)熱了起來. 于是就有了jsf這種世界上最奇怪的技術(shù)出來,明明可以在客戶機(jī)上做的事情,非要到服務(wù)器上去做,你說這是何苦來著? 4.5 Hibernate是垃圾我個(gè)人的觀點(diǎn),Hibernate這種東西純粹是垃圾. 看到這里有人要跳腳了,這么

47、高級(jí)的東西,你豈敢污蔑于它. 且慢著急上火,先冷靜下來,這個(gè)觀點(diǎn)是我最近重新研究VB這種古老的語言,才得出的結(jié)論. 在VB的世界里面,是沒有所謂的ORM這種東西的,相對(duì)應(yīng)的,有ADO Data控件,你只要給這個(gè)控件一個(gè)SQL語句,它就會(huì)自動(dòng)和數(shù)據(jù)庫建立關(guān)聯(lián). 包括表,字段這些都可以,以后的修改只要把Ado里面的數(shù)據(jù)改了,就可以自動(dòng)更新到后臺(tái)數(shù)據(jù)庫去. 在一個(gè)沒有所謂ORM的世界里面,寫程序不僅是可能的,而且更加簡(jiǎn)單,更加方便. 現(xiàn)在回顧一下Hibernate要解決的問題是從那里來的,根本的原因就是Java語言教條的把一切都看成對(duì)象,萬事萬物皆對(duì)象,走火入魔的結(jié)果就是把數(shù)據(jù)也看成了對(duì)象,因此必須

48、把數(shù)據(jù)庫的數(shù)據(jù)映射成一個(gè)對(duì)象,一個(gè)對(duì)象集合才能理解,才能操作,否則就覺得不夠爽. 其實(shí)何必呢?數(shù)據(jù)就是數(shù)據(jù),為啥非要自找苦吃,先把它轉(zhuǎn)成個(gè)對(duì)象,然后操作這個(gè)對(duì)象,然后再把這個(gè)對(duì)象變成數(shù)據(jù),為了這種復(fù)雜的轉(zhuǎn)換,最后還要發(fā)明出一個(gè)ORM的工具,來試圖簡(jiǎn)化這個(gè)ORM的過程. 如果這個(gè)ORM的過程根本上就是不需要的,那么又何必存在Hibernate這種東西呢? 既然在十年以前的大量軟件實(shí)踐中,已經(jīng)證明沒有ORM這些怪異的東西照樣可以寫出很復(fù)雜,很強(qiáng)壯的程序,為啥一定要在系統(tǒng)里面加入這些怪物呢? 我之所以說Hibernate是垃圾,理由就是它在試圖解決一個(gè)原本本來根本不存在的問題,而在解決這個(gè)問題的同時(shí)

49、,自己又變成了新的問題. 4.6為什么J2EE如此低效-用戶無法參與開發(fā)關(guān)鍵字: j2ee 論壇訪問地址(有回復(fù),已經(jīng)隱藏) 這是從網(wǎng)上搜到的一個(gè)J2EE的定義. J2EE是一種利用Java 2平臺(tái)來簡(jiǎn)化企業(yè)解決方案的開發(fā)、部署和管理相關(guān)的復(fù)雜問題的體系結(jié)構(gòu)。J2EE技術(shù)的基礎(chǔ)就是核心Java平臺(tái)或Java 2平臺(tái)的標(biāo)準(zhǔn)版，J2EE不僅鞏固了標(biāo)準(zhǔn)版中的許多優(yōu)點(diǎn)，例如"編寫一次、隨處運(yùn)行"的特性、方便存取數(shù)據(jù)庫的JDBC API、CORBA技術(shù)以及能夠在Internet應(yīng)用中保護(hù)數(shù)據(jù)的安全模式等等，同時(shí)還提供了對(duì) EJB（Enterprise JavaBeans）、Java

50、Servlets API、JSP（Java Server Pages）以及XML技術(shù)的全面支持。其最終目的就是成為一個(gè)能夠使企業(yè)開發(fā)者大幅縮短投放市場(chǎng)時(shí)間的體系結(jié)構(gòu)。 J2EE體系結(jié)構(gòu)提供中間層集成框架用來滿足無需太多費(fèi)用而又需要高可用性、高可靠性以及可擴(kuò)展性的應(yīng)用的需求。通過提供統(tǒng)一的開發(fā)平臺(tái)，J2EE降低了開發(fā)多層應(yīng)用的費(fèi)用和復(fù)雜性，同時(shí)提供對(duì)現(xiàn)有應(yīng)用程序集成強(qiáng)有力支持，完全支持Enterprise JavaBeans，有良好的向?qū)еС执虬筒渴饝?yīng)用，添加目錄支持，增強(qiáng)了安全機(jī)制，提高了性能。原始的連接在這里: 問題是:出于如此美好目的設(shè)計(jì)的技術(shù),最后為何會(huì)變得如此低效,如此難以開發(fā),難以

51、維護(hù)呢? 原因當(dāng)然是很多很多了.不同人有不同見解都是很正常的.要把所有原因分析討論完,怕是用盡所有的時(shí)間和硬盤也是不夠的. 在我看來,其中一個(gè)很重要的原因,就是在J2EE的整個(gè)開發(fā)維護(hù)過程中,在項(xiàng)目的整個(gè)生命周期里面,用戶的作用被忽視了,在整個(gè)J2EE的設(shè)計(jì)思路里面,根本沒有考慮過最終用戶將如何參與到整個(gè)系統(tǒng)的開發(fā),設(shè)計(jì),使用,以及后續(xù)的運(yùn)維中來. 這才是J2EE整個(gè)理論體系的最致命缺陷.雖然目前隨著RIA應(yīng)用的推廣,J2EE本身也在進(jìn)行著演化,但到目前為止,整個(gè)理論體系仍然沒有突破這一限制. J2EE本身的基本理論基礎(chǔ),是以服務(wù)器為中心的設(shè)計(jì)思想,一切工作都在服務(wù)器上來完成和實(shí)現(xiàn).客戶端是為

52、服務(wù)器來服務(wù)的.在J2EE的整個(gè)理論體系里面,沒有考慮用戶界面應(yīng)該如何優(yōu)化,也沒有考慮用戶的實(shí)際體驗(yàn)將是怎樣的.J2EE關(guān)注的重點(diǎn)和核心是后臺(tái)的服務(wù)器. 作為一個(gè)理論體系,J2EE是完整的,也是相當(dāng)復(fù)雜,難以全部掌握的. 在實(shí)際項(xiàng)目中,用戶的參與是非常重要的,在項(xiàng)目的開發(fā)中,用戶不僅給出建議意見,在后續(xù)的維護(hù)中,更是用戶本身需要對(duì)系統(tǒng)的進(jìn)一步發(fā)展演化來進(jìn)行把關(guān). 可以在J2EE的項(xiàng)目里面,用戶想?yún)⑴c到項(xiàng)目的整個(gè)開發(fā)過程中來,實(shí)在是太困難了. 用戶所能夠理解和發(fā)表意見的部分,在整個(gè)項(xiàng)目里面,是用戶的界面部分,操作的流程部分.這一部分,本身也是用戶日后使用中實(shí)際接觸的部分. 而按照J(rèn)2EE的開發(fā)模

53、式,絕大部分精力都花費(fèi)在了中間層的J2EE技術(shù)上面,不同J2ee服務(wù)器之間的差異,各個(gè)開源框架之間的協(xié)調(diào),各種技術(shù)bug的處理.所有這些把開發(fā)人員的時(shí)間和精力全部耗盡了,根本沒有余力來和用戶討論界面該如何組織,操作流程如何優(yōu)化. - 問題的另外一個(gè)方面,就是基于j2ee的開發(fā)模式下,界面的開發(fā)實(shí)在是太過困難了. 一旦你采用J2ee的技術(shù)架構(gòu),前臺(tái)的用戶界面,幾乎都選擇采用HTML語言來編寫,這樣的選擇也不難理解.J2ee剛出來的時(shí)候,當(dāng)時(shí)只有HTML和Applet可以選用,當(dāng)時(shí)javascript還沒有發(fā)展到今天的地步.一旦你的技術(shù)團(tuán)隊(duì)選擇了java語言,其他方向的技術(shù)人員自然也就不在考慮范圍

54、之內(nèi)了.大家都用HTML來寫頁面了. 但問題是,HTML語言來編寫應(yīng)用程序的界面,實(shí)在是太困難的一件事情. - 如果只使用標(biāo)準(zhǔn)的HTML語言,不使用任何的樣式表的話,那么這個(gè)界面實(shí)在是太難看了. 而使用CSS的話,寫這樣的界面又增加了新的困難程度. 對(duì)了,現(xiàn)在還沒有說JavaScript呢,在頁面上增加javascript,在增加頁面功能的同時(shí),也增加了頁面長(zhǎng)度,這些增加的代碼,對(duì)于以后的系統(tǒng)維護(hù),都是一顆顆地雷,后續(xù)者必須以百倍的熱情和謹(jǐn)慎,才能不被這些地雷炸傷. - 上面的討論還是僅僅是在技術(shù)層次上進(jìn)行的,其實(shí)還有更重要的一個(gè)方面沒有談到. 這就是界面開發(fā)上的所見即所得.由于Web界面開發(fā)的復(fù)雜性,沒有一個(gè)開發(fā)工具可以實(shí)現(xiàn)真正的所見即所得,只能在運(yùn)行的時(shí)候才知道最終的結(jié)果到底是怎么樣的. 在這種情況下,除了增加開發(fā)的復(fù)雜度以外,用戶也就被排斥到了整個(gè)開發(fā)過程之外. 用戶沒有辦法對(duì)界面提出自己的要求,一是這種要求會(huì)被回應(yīng):對(duì)不起,做不到.對(duì)不起,難度太大.二是在整個(gè)界面的開發(fā)過程中,用戶本身是隔離其中的,用戶無法真正理解界面開發(fā)的全部過程,也就無法提出合適的意見出來. - 這種將用戶隔絕在界面開發(fā)過程的惡果,就是用戶對(duì)最后的界面,包