從Java EE的三個層次看高質(zhì)量的系統(tǒng)標準
我們從一個發(fā)展角度來對J2EE/Java EE的這些框架誕生進行一番考量，可能對我們的選擇有很大幫助。
首先我們需要明白一個高質(zhì)量的J2EE系統(tǒng)是什么樣子？高質(zhì)量的J2EE/Java EE系統(tǒng)標準實際就是OO設(shè)計的標準，松耦合是OO設(shè)計的主要追求目標之一，那么無疑解耦性成為衡量J2EE/JEE質(zhì)量的首要標準。實際選擇中，還需要兼顧可伸縮性/性能/開發(fā)效率等方面綜合考慮。
J2EE/Java EE號稱多層結(jié)構(gòu)，為什么多層比兩層好？因為多層結(jié)構(gòu)解耦性好，帶來維護拓展方便靈活。
典型的J2EE/Java EE至少劃分三個層次：表現(xiàn)層/業(yè)務邏輯組件層/持久層。
表現(xiàn)層英文是Presentation Layer，是實現(xiàn)顯示功能的，這部分一般使用B/S結(jié)構(gòu)來完成，當然你也可以使用專門遠程客戶端來實現(xiàn);
業(yè)務邏輯層因為是由大量組件(Components)組成的，也可稱為組件層，組件從不同角度又可分為各種類型，然后又有不同的流派，目前占主要位置的是Model+Service，模型加服務，所以這一層又稱為業(yè)務服務層Business Service;也有稱為Model業(yè)務層;
持久層是負責對象持久化也就是數(shù)據(jù)庫操作的層次,英文Persistence Layer。
SUN伙伴們推出J2EE標準時，分別對這三個層次規(guī)定了標準實現(xiàn)，表現(xiàn)層使用Jsp/Servlet技術(shù);業(yè)務組件層使用EJB的會話Bean;持久層使用實體Bean。同時，標準將業(yè)務層和持久層在物理上組成一個新的容器EJB容器，與表現(xiàn)層技術(shù)完全一樣的容器，這樣，J2EE技術(shù)被細化為Web和EJB，物理上有Web容器和Web應用程序;以及EJB容器和EJB應用程序。
當然，J2EE/JEE的發(fā)展不止這些，這三個層次技術(shù)分別獨立發(fā)展，高歌猛進，下面分別單獨陳述，當你了解某種框架技術(shù)為什么誕生時，你可能就知道你該在什么情況下選擇它們了，工具總是因目的而生!
Java EE的三個層次之表現(xiàn)層框架
J2EE/Java EE雖是多層結(jié)構(gòu)，但它不是一種強制性多層結(jié)構(gòu)，也就是說，你也可能做成傳統(tǒng)兩層結(jié)構(gòu)，有的初學者直接使用Jsp嵌入Java代碼調(diào)用數(shù)據(jù)庫這樣結(jié)構(gòu)實際不是多層結(jié)構(gòu)，還是以前的兩層結(jié)構(gòu)。
在Jsp中嵌入大量代碼，一旦報空指針錯誤就很難找出問題，很多初學者下載JiveJdon 2.5后就經(jīng)常碰到這個問題，因此大量有關(guān)空指針錯誤問題出現(xiàn)論壇里，為什么他們不能自己解決呢? 那是因為無法定位錯誤在Jsp中的位置，Tomcat等服務器只告訴我們錯誤在index_jsp.java(Jsp的java文件)位置，搞得一些人經(jīng)常會跑到Tomcat服務器內(nèi)部翻找Jsp的Java文件，這一過程無比痛苦(為了減少初學者這種痛苦，本站暫停了JiveJdon2.5的下載)。
J2EE/Java EE的發(fā)展就是降低這種痛苦，首先想到的方式是：在Jsp調(diào)試上下苦功，要求Tomcat等服務器提供詳細的錯誤定位;可惜到Tomcat 5.5我們也沒看到這種功能;實際上，根本解決之道就是將Jsp的調(diào)試變成java組件的調(diào)試。
首先通過MVC模式規(guī)定Jsp只能等同于Html，不能包含Java代碼，將Jsp和Java代碼分離，可是這樣分離之后，它們結(jié)合起來又麻煩了，所以，雖然你使用MVC模式，但是還是直接基于Jsp技術(shù)，帶來的是開發(fā)效率的降低。
Struts框架解決了這個問題，通過ActionForm可以將Jsp和JavaBeans方便快速地結(jié)合起來，但是有人又抱怨Struts的ActionForm限制太死，與Jsp雖能對應，只能一個ActionForm一個表單對應，而不能任意組件JavaBeans都可以和Jsp任意字段對應，這時就出來了組件型框架JSF/Tapestry。
Java EE的三個層次至業(yè)務邏輯層框架
可伸縮性
因為EJB標準的推出，業(yè)務組件層以前基本是EJB的天下，但是EJB功能實在太強大，它考慮了世界頂級大型系統(tǒng)需求，因此免不了顯得很復雜，當初，基本上所有的大型企業(yè)高端都是選用J2EE，選用J2EE實際是選用EJB。EJB強調(diào)的高可伸縮性為大型企業(yè)日益發(fā)展提供最大的發(fā)展空間，不再因為企業(yè)快速發(fā)展導致整個企業(yè)系統(tǒng)結(jié)構(gòu)都要發(fā)生根本變化,這是使用EJB的現(xiàn)實優(yōu)勢。
這種企業(yè)系統(tǒng)的可伸縮性不是因為EJB存在才顯得重要，而是我們企業(yè)架構(gòu)選擇需要考量的基本因素。換句話說，無論我們使用EJB與否，這個問題都需要考慮:一臺服務器不夠用怎么辦?如果這臺服務器死機會對企業(yè)運營帶來什么影響?如果每個星期這臺服務器停機維護升級會不會對企業(yè)帶來打擊?我的企業(yè)系統(tǒng)是不是需要可靠的、幾乎不當機的7x24運行?當企業(yè)系統(tǒng)面對大量外部訪問用戶時，一臺服務器是否夠用?多臺服務器聯(lián)動的需求是否涉及軟件技術(shù)更換?
在這個現(xiàn)實因素考量后，如果覺得不是很重要，或者說將來一段時間內(nèi)這些因素無所謂，那么可以不選用EJB了。
為什么有不選用EJB的理由?因為它復雜，學習起來比較困難，EJB幫助我們考慮企業(yè)中可能碰到的大部分問題，實際上，有的我們不需要，這也就是為什么說EJB是一個重量級解決方案所在。
與重量級相比的是輕量，業(yè)務組件層輕量級解決方案有Spring/HiveMidn/Jdon Framework等，輕量一詞曾經(jīng)因為EJB的出現(xiàn)而變得時髦，給人造成的感覺是：EJB花了老鼻子力氣完成的那些功能，使用我輕量級解決方案可以輕而易舉也能解決，舉重若輕啊，其實這是一種誤解。
當曾經(jīng)以輕量自居的Spring將事務機制納入自己懷抱中時，它也開始低調(diào)輕量了，實際是不輕不重了;當然如果它把分布式計算和事務再次加入時，天平砝碼也會沉下去的。
初學者總是愿意使用簡單的解決方案，學習使用方便，因此比較喜歡輕量級框架技術(shù)，這是正常的，但是在使用輕量級別框架之前必須明白：你的系統(tǒng)將來真的只需要一臺服務器即可?你的項目完成期真的非常緊急?
如果只需要一臺巨強服務器，就不必選擇EJB，EJB是因分布式多服務器而生，對于單臺服務器，缺乏本地透明性，也就是說：你無法透過EJB直接和本地JVM或文件系統(tǒng)等打交道，透明性也是衡量一個框架的重要指標。
當然，重量和輕量并不完全對立，EJB3就是為了簡化J2EE的使用，使得EJB不只是擅長處理大型企業(yè)系統(tǒng)，中小型系統(tǒng)也使用很方便，這實際上也是EJB輕量化的一種努力。什么是Java EE 5?
所以，對于架構(gòu)選擇來說，根本前提是需要明白你的系統(tǒng)現(xiàn)在或?qū)硪欢螘r間(注意需要考慮將來一段時間，不能只看眼前)是中小型系統(tǒng)還是大型系統(tǒng)?
靈活性/定制性/透明性
當然這個答案有時我們自己也可能很難給出，那么我們還需要從其他角度來考量EJB和非EJB之選，例如筆者曾經(jīng)經(jīng)歷一個大型實時娛樂平臺社區(qū)系統(tǒng)，從規(guī)模上說肯定是大型系統(tǒng)，設(shè)計目標10萬人在線，從這個角度非選用EJB不可!
但是，EJB因為還有事務機制，雖然應用程序可以選擇失效EJB事務，但是EJB容器設(shè)計因為考慮了事務，所以在其內(nèi)核上總是會顯得臃腫，是一種累贅，這也是一種重量表示，不需要的東西存在肯定會影響效率，那么難道我不能根據(jù)我的需求，對EJB整體包括EJB容器進行可配置式的切割?也就是說，我上面這個案例只需要EJB的分布式計算功能，其他的功能我都拆除，只剩余我需要的功能能運行就可以了，輕裝上陣。
可惜，這種任意切割，應需而定的目標在EJB3標準還沒有被重視，所幸的是，Ioc/AOP技術(shù)為這種目標實現(xiàn)提供了實現(xiàn)可能，但是，只有Ioc/AOP還是不夠，特別是看Ioc的范圍，如果你只把應用系統(tǒng)組件納入Ioc管理時，自由解耦只屬于應用系統(tǒng)，我上面案例的目標還是無法達到，當你把框架本身組件也納入Ioc管理時，任意切割，應需而定的目標才真正實現(xiàn)。
Spring和EJB3屬于“只把應用系統(tǒng)組件納入Ioc管理”，這從JBoss 4.0版本可以看出;那什么框架會把框架本身組件也納入Ioc管理呢?Apache的Hivemind和筆者開發(fā)的Jdon框架。
什么樣的組件可以被納入Ioc管理呢?POJO組件，POJO這個概念其實當初是針對EJB缺點而推出，EJB要求應用系統(tǒng)的組件必須繼承或依賴EJB容器，這樣使得調(diào)試變的不方便，但是后來，POJO的概念已經(jīng)不只最初這些概念，POJO代表那種與周圍完全脫離關(guān)系、自由自在的Object了，如果應用系統(tǒng)的Model或者Service都是POJO，意味著你的應用系統(tǒng)不依賴任何其他系統(tǒng)，解耦性靈活性高。
POJO是因為EJB而提出的，當EJB自己傾向POJO時，大家都在宣稱自己是POJO時，POJO概念就沒有立足點了，這也是Java領(lǐng)域哭笑不得的現(xiàn)象，但是我個人更傾向把非EJB的JavaBeans組件通稱為POJO。
Hivemind的Ioc依賴注射部分功能和Jdon框架非常類似，當上百個POJO組件配置時，完全不必指定它們之間的依賴關(guān)系;你可以將自己應用程序的組件注冊到Registry中，這樣Hivemind將幫助你啟動這些組件，正如你在Jdon框架中將你的組件寫入mycontainer.xml中，Jdon框架也將自動啟動你這些組件，并解決它們之間的互相調(diào)用，包括和框架本身組件互動。
HiveMind和Jdon框架定義的POJO Service有如下特點：
不象EJB那樣缺乏本地透明化(location transparency)概念，這些POJO Service總是能定位到同樣一個JVM;也不象基于XML的Web服務web services那樣沒有語言透明(language transparency)概念，這些POJO Service總是可以被一組Java接口來概括替代(通過調(diào)用Java interface來替代調(diào)用這些具體Service);當然，更不會類似JMX或Jini，不能進行service的熱裝載( hot-loading)。
注意：當Ioc/AOP提供高度靈活的同時，已經(jīng)有初學者開始抱怨Spring的過分靈活，那么比Spring在組件上更靈活的Jdon框架只能算是一種追求極端，它不一定構(gòu)成你進行架構(gòu)選擇的主要依據(jù)!
上面這些討論只是表明在靈活性(解耦性/透明性)這條需求道路上深究下去的選擇，你自己的應用系統(tǒng)需求會產(chǎn)生各種不同的要求，有些要求甚至是極致的，這種偏向程度就成為你架構(gòu)選擇的目標，如果你的這種極致要求在目前Java世界里還沒有可選框架時，那么你就要動手自己做了，這也說明什么時候你開始自己做框架(如Jdon框架)，雖然在大多數(shù)情況下我們是不必要自己發(fā)明輪子的。
快速構(gòu)建性
前面是從靈活性和定制性這個角度討論架構(gòu)選擇目標，但是在一般情況下，我們還是從上手難易、開發(fā)效率這個角度來進行架構(gòu)選擇，從這個角度來說，就是需要我們將選用的框架盡可能的多幫助我們實現(xiàn)一些功能，但這又是和使用難易是矛盾的，因此有個取舍問題，取舍有個準則：這個框架盡量能提供越多功能;盡量需要我們少寫代碼，甚至不寫代碼(使用XML配置)，少動腦筋。
關(guān)于XML配置這里也涉及難易問題，XML配置語法不能太復雜，有太多小開關(guān)Switch也增加學習成本。
從這個角度看，EJB無論是EJB2或EJB3提供的功能是最齊全的，但是XML配置開關(guān)太多 ，Spring屬于中等，組件XML配置不算簡單，但是因為有不少Struts+Spring+Hibernate之類現(xiàn)成開源代碼可供參考，因此學習起來難度也不大，Spring越來越象一個J2EE API(注意，JDK是J2SE API) ，Spring除不能提供分布式計算外，也因為過分靈活降低了一些開發(fā)效率，例如它的組件依賴關(guān)系一般需要逐步指定，auotwiring功能還沒有深入骨髓成為核心功能。Ioc容器的革命性優(yōu)點。
Spring除了提供組件層功能以外，還有表現(xiàn)層支持Spring MVC;也有持久層實現(xiàn)的JDBC模板，這樣，整個J2EE/Java EE系統(tǒng)各個層次Spring都提供了缺省實現(xiàn)，在這方面無疑提高了開發(fā)效率，但是Spring提供豐富API目的好像不是為了快速開發(fā)，而是為了建立一個完整的功能齊全的API功能庫。正如它網(wǎng)頁上開頭文字所述：As the leading full-stack Java/J2EE application framework，注意full-stack(完整齊全)是它突出的名詞。
那么，還有另外一個空白，就是以開發(fā)效率為主要考慮，這類框架除了必須考慮足夠靈活性和豐富功能以外，宗旨是為了在一般缺省情況下快速完成一個J2EE/Java EE系統(tǒng)，這非常類似MDA工具了，但是一個完全喪失靈活性和定制性的MDA工具也不是我們歡迎的。
Jdon框架的發(fā)展目標是為了填補這個空白，相信也會越來越多框架向這個目標邁進，當然不可否認，Spring也可能調(diào)轉(zhuǎn)槍頭走入這個領(lǐng)域，EJB2/EJB3正依靠JBuilder等這樣商業(yè)化開發(fā)工具向這個領(lǐng)域靠攏，這個發(fā)展方向?qū)嶋H是4GL RAD Tools。
很多人在快速構(gòu)建方面也很早進行了探索，涌現(xiàn)出各種工具：如何構(gòu)建一個快速業(yè)務構(gòu)件平臺? 但是如何把快速構(gòu)建和構(gòu)件(組件)靈活性有機結(jié)合在一起?它是考驗一個業(yè)務構(gòu)件(業(yè)務組件)平臺好壞的準則。有些構(gòu)件平臺雖然開發(fā)迅速，但是對于特殊情況，可供程序員定制透明操作部分不多，很死，典型的是兩層結(jié)構(gòu)以前的Delphi，開發(fā)很快速，但是無法象J2EE這樣深入到系統(tǒng)各個層次進行定制/維護/拓展!
Java EE的三個層次之持久層框架
持久層框架目前有EJB2/EJB3的實體Bean、Hibernate和各種JDO產(chǎn)品，當然還有直接寫SQL語句的JDBC，如iBatis等。
持久層框架質(zhì)量好與壞區(qū)分就是是否是O/R Mapping，也就是對象和關(guān)系數(shù)據(jù)庫映射，關(guān)系數(shù)據(jù)庫需要實現(xiàn)定義好Schema結(jié)構(gòu);對象因為字段而變的也有一個自己的結(jié)構(gòu)，如何將對象數(shù)據(jù)自動持久化到數(shù)據(jù)庫中，首先我們得定義兩者結(jié)構(gòu)的對應，這實際是數(shù)據(jù)的元數(shù)據(jù)定義。
因為Hiberante/Toplink/JDO這樣O/R Mapping工具幫助你實現(xiàn)對象和數(shù)據(jù)庫轉(zhuǎn)換，克服了對象和數(shù)據(jù)庫阻抗現(xiàn)象，O/R Mapping總結(jié) ，所以才使得我們更多的可以對象方式(從模型Model對象)來考慮Java EE/J2EE系統(tǒng)，可以完全放棄以前那種以數(shù)據(jù)庫為中心的思維方式：數(shù)據(jù)庫時代的終結(jié)。
所以，是否選用好的持久層框架，取決于你整個團隊思維是否徹底OO了，是否需要真正OO，當然，對于一些小型項目，有時我們覺得直接使用JDBC模板反而更加輕松快捷一點，這也是Spring的JDBC模板/iBatis/Jdon的Jdbc模板存在的理由了。
例如新增一個數(shù)據(jù)表，在Jdon框架只需要下面幾行代碼即可：
- String sql = "INSERT INTO testuser (userId , name) VALUES (?, ?)";
- List queryParams = new ArrayList();
- queryParams.add(userTest.getUserId());
- queryParams.add(userTest.getName());
- jdbcTemp.operate(queryParams,sql);
這種方式和O/R Mapping興師動眾的多個XML配置和關(guān)系映射思考相比，對于習慣SQL語句的程序員反而更加迅速。
從以上可以看出，靈活性/快速性/簡單性/可伸縮性是我們進行架構(gòu)選擇的主要幾個依據(jù)，架構(gòu)選擇實際就是在這幾個策略之間做一個平衡。當然，還有一個非常重要的因素，因為它不屬于某個層次的技術(shù)，性能/緩存是必須和上面因素綜合考慮的因素。
【編輯推薦】
