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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30、發展自定義ActiveX 大發展JavaScript逐漸衰退服務器進一步弱化，弱化為為前臺提供必要服務，應用中心轉移通過Ajax技術,利用DWR等工具。瀏覽器終于把握了應用的全面主動權。從整體上來看，整個應用架構的發展，體現了從理想的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為標準用戶界面；可能內嵌一個自定義的界面渲染工具；以純靜態HTML頁面為主少數以JSP形式提供，動態生成以瀏覽器為主，服務器

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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