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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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