現(xiàn)在Java領(lǐng)域各種技術(shù)百花齊放，名目繁多，如何根據(jù)自己的需求選擇這些框架呢？特別對(duì)于初學(xué)者，在學(xué)習(xí)選擇方向上也非常迷茫，如何有針對(duì)性的根據(jù)自己項(xiàng)目特點(diǎn)進(jìn)行學(xué)習(xí)就變的更加重要。

　　下面我們從一個(gè)發(fā)展角度來(lái)對(duì)J2EE/Java EE的這些框架誕生進(jìn)行一番考量，可能對(duì)我們的選擇有很大幫助。

　　首先我們需要明白一個(gè)高質(zhì)量的J2EE系統(tǒng)是什么樣子？高質(zhì)量的J2EE/Java EE系統(tǒng)標(biāo)準(zhǔn)實(shí)際就是OO設(shè)計(jì)的標(biāo)準(zhǔn)，松耦合是OO設(shè)計(jì)的主要追求目標(biāo)之一，那么無(wú)疑解耦性成為衡量J2EE/JEE質(zhì)量的首要標(biāo)準(zhǔn)。實(shí)際選擇中，還需要兼顧可伸縮性/性能/開(kāi)發(fā)效率等方面綜合考慮。

　　J2EE/Java EE號(hào)稱(chēng)多層結(jié)構(gòu)，為什么多層比兩層好？因?yàn)槎鄬咏Y(jié)構(gòu)解耦性好，帶來(lái)維護(hù)拓展方便靈活。

　　典型的J2EE/Java EE至少劃分三個(gè)層次：表現(xiàn)層/業(yè)務(wù)邏輯組件層/持久層。

　　如圖，表現(xiàn)層英文是Presentation Layer，是實(shí)現(xiàn)顯示功能的，這部分一般使用B/S結(jié)構(gòu)來(lái)完成，當(dāng)然你也可以使用專(zhuān)門(mén)遠(yuǎn)程客戶(hù)端來(lái)實(shí)現(xiàn);

　　業(yè)務(wù)邏輯層因?yàn)槭怯纱罅拷M件(Components)組成的，也可稱(chēng)為組件層，組件從不同角度又可分為各種類(lèi)型，然后又有不同的流派，目前占主要位置的是Model+Service，模型加服務(wù)，所以這一層又稱(chēng)為業(yè)務(wù)服務(wù)層Business Service；也有稱(chēng)為Model業(yè)務(wù)層；

　　持久層是負(fù)責(zé)對(duì)象持久化也就是數(shù)據(jù)庫(kù)操作的層次,英文Persistence Layer。

　　SUN伙伴們推出J2EE標(biāo)準(zhǔn)時(shí)，分別對(duì)這三個(gè)層次規(guī)定了標(biāo)準(zhǔn)實(shí)現(xiàn)，表現(xiàn)層使用Jsp/Servlet技術(shù)；業(yè)務(wù)組件層使用EJB的會(huì)話(huà)Bean；持久層使用實(shí)體Bean。同時(shí)，標(biāo)準(zhǔn)將業(yè)務(wù)層和持久層在物理上組成一個(gè)新的容器EJB容器，與表現(xiàn)層技術(shù)完全一樣的容器，這樣，J2EE技術(shù)被細(xì)化為Web和EJB，物理上有Web容器和Web應(yīng)用程序；以及EJB容器和EJB應(yīng)用程序。

　　當(dāng)然，J2EE/JEE的發(fā)展不止這些，這三個(gè)層次技術(shù)分別獨(dú)立發(fā)展，高歌猛進(jìn)，下面分別單獨(dú)陳述，當(dāng)你了解某種框架技術(shù)為什么誕生時(shí)，你可能就知道你該在什么情況下選擇它們了，工具總是因目的而生！

表現(xiàn)層框架

　　J2EE/Java EE雖是多層結(jié)構(gòu)，但它不是一種強(qiáng)制性多層結(jié)構(gòu)，也就是說(shuō)，你也可能做成傳統(tǒng)兩層結(jié)構(gòu)，有的初學(xué)者直接使用Jsp嵌入Java代碼調(diào)用數(shù)據(jù)庫(kù)這樣結(jié)構(gòu)實(shí)際不是多層結(jié)構(gòu)，還是以前的兩層結(jié)構(gòu)。

　　在Jsp中嵌入大量代碼，一旦報(bào)空指針錯(cuò)誤就很難找出問(wèn)題，很多初學(xué)者下載JiveJdon 2.5后就經(jīng)常碰到這個(gè)問(wèn)題，因此大量有關(guān)空指針錯(cuò)誤問(wèn)題出現(xiàn)論壇里，為什么他們不能自己解決呢？ 那是因?yàn)闊o(wú)法定位錯(cuò)誤在Jsp中的位置，Tomcat等服務(wù)器只告訴我們錯(cuò)誤在index_jsp.java(Jsp的java文件)位置，搞得一些人經(jīng)常會(huì)跑到Tomcat服務(wù)器內(nèi)部翻找Jsp的Java文件，這一過(guò)程無(wú)比痛苦（為了減少初學(xué)者這種痛苦，本站暫停了JiveJdon2.5的下載）。

　　J2EE/Java EE的發(fā)展就是降低這種痛苦，首先想到的方式是：在Jsp調(diào)試上下苦功，要求Tomcat等服務(wù)器提供詳細(xì)的錯(cuò)誤定位；可惜到Tomcat 5.5我們也沒(méi)看到這種功能；實(shí)際上，根本解決之道就是將Jsp的調(diào)試變成java組件的調(diào)試。

　　首先通過(guò)MVC模式規(guī)定Jsp只能等同于Html，不能包含Java代碼，將Jsp和Java代碼分離，可是這樣分離之后，它們結(jié)合起來(lái)又麻煩了，所以，雖然你使用MVC模式，但是還是直接基于Jsp技術(shù)，帶來(lái)的是開(kāi)發(fā)效率的降低。

　　Struts框架解決了這個(gè)問(wèn)題，通過(guò)ActionForm可以將Jsp和JavaBeans方便快速地結(jié)合起來(lái)，但是有人又抱怨Struts的ActionForm限制太死，與Jsp雖能對(duì)應(yīng)，只能一個(gè)ActionForm一個(gè)表單對(duì)應(yīng)，而不能任意組件JavaBeans都可以和Jsp任意字段對(duì)應(yīng)，這時(shí)就出來(lái)了組件型框架JSF/Tapestry。

　　表現(xiàn)層框架Struts/Tapestry/JSF架構(gòu)比較

業(yè)務(wù)邏輯層框架

可伸縮性

　　因?yàn)镋JB標(biāo)準(zhǔn)的推出，業(yè)務(wù)組件層以前基本是EJB的天下，但是EJB功能實(shí)在太強(qiáng)大，它考慮了世界頂級(jí)大型系統(tǒng)需求，因此免不了顯得很復(fù)雜，當(dāng)初，基本上所有的大型企業(yè)高端都是選用J2EE，選用J2EE實(shí)際是選用EJB。EJB強(qiáng)調(diào)的高可伸縮性為大型企業(yè)日益發(fā)展提供最大的發(fā)展空間，不再因?yàn)槠髽I(yè)快速發(fā)展導(dǎo)致整個(gè)企業(yè)系統(tǒng)結(jié)構(gòu)都要發(fā)生根本變化,這是使用EJB的現(xiàn)實(shí)優(yōu)勢(shì)。

　　這種企業(yè)系統(tǒng)的可伸縮性不是因?yàn)镋JB存在才顯得重要，而是我們企業(yè)架構(gòu)選擇需要考量的基本因素。換句話(huà)說(shuō)，無(wú)論我們使用EJB與否，這個(gè)問(wèn)題都需要考慮:一臺(tái)服務(wù)器不夠用怎么辦？如果這臺(tái)服務(wù)器死機(jī)會(huì)對(duì)企業(yè)運(yùn)營(yíng)帶來(lái)什么影響？如果每個(gè)星期這臺(tái)服務(wù)器停機(jī)維護(hù)升級(jí)會(huì)不會(huì)對(duì)企業(yè)帶來(lái)打擊？我的企業(yè)系統(tǒng)是不是需要可靠的、幾乎不當(dāng)機(jī)的7x24運(yùn)行？當(dāng)企業(yè)系統(tǒng)面對(duì)大量外部訪(fǎng)問(wèn)用戶(hù)時(shí)，一臺(tái)服務(wù)器是否夠用？多臺(tái)服務(wù)器聯(lián)動(dòng)的需求是否涉及軟件技術(shù)更換？

　　在這個(gè)現(xiàn)實(shí)因素考量后，如果覺(jué)得不是很重要，或者說(shuō)將來(lái)一段時(shí)間內(nèi)這些因素?zé)o所謂，那么可以不選用EJB了。

　　為什么有不選用EJB的理由？因?yàn)樗鼜?fù)雜，學(xué)習(xí)起來(lái)比較困難，EJB幫助我們考慮企業(yè)中可能碰到的大部分問(wèn)題，實(shí)際上，有的我們不需要，這也就是為什么說(shuō)EJB是一個(gè)重量級(jí)解決方案所在。

　　與重量級(jí)相比的是輕量，業(yè)務(wù)組件層輕量級(jí)解決方案有Spring/HiveMidn/Jdon Framework等，輕量一詞曾經(jīng)因?yàn)镋JB的出現(xiàn)而變得時(shí)髦，給人造成的感覺(jué)是：EJB花了老鼻子力氣完成的那些功能，使用我輕量級(jí)解決方案可以輕而易舉也能解決，舉重若輕啊，其實(shí)這是一種誤解。

　　當(dāng)曾經(jīng)以輕量自居的Spring將事務(wù)機(jī)制納入自己懷抱中時(shí)，它也開(kāi)始低調(diào)輕量了，實(shí)際是不輕不重了；當(dāng)然如果它把分布式計(jì)算和事務(wù)再次加入時(shí)，天平砝碼也會(huì)沉下去的。

　　初學(xué)者總是愿意使用簡(jiǎn)單的解決方案，學(xué)習(xí)使用方便，因此比較喜歡輕量級(jí)框架技術(shù)，這是正常的，但是在使用輕量級(jí)別框架之前必須明白：你的系統(tǒng)將來(lái)真的只需要一臺(tái)服務(wù)器即可？你的項(xiàng)目完成期真的非常緊急？

　　如果只需要一臺(tái)巨強(qiáng)服務(wù)器，就不必選擇EJB，EJB是因分布式多服務(wù)器而生，對(duì)于單臺(tái)服務(wù)器，缺乏本地透明性，也就是說(shuō)：你無(wú)法透過(guò)EJB直接和本地JVM或文件系統(tǒng)等打交道，透明性也是衡量一個(gè)框架的重要指標(biāo)。

　　當(dāng)然，重量和輕量并不完全對(duì)立，EJB3就是為了簡(jiǎn)化J2EE的使用，使得EJB不只是擅長(zhǎng)處理大型企業(yè)系統(tǒng)，中小型系統(tǒng)也使用很方便，這實(shí)際上也是EJB輕量化的一種努力。什么是Java EE 5？

　　所以，對(duì)于架構(gòu)選擇來(lái)說(shuō)，根本前提是需要明白你的系統(tǒng)現(xiàn)在或?qū)?lái)一段時(shí)間（注意需要考慮將來(lái)一段時(shí)間，不能只看眼前）是中小型系統(tǒng)還是大型系統(tǒng)？

靈活性/定制性/透明性

　　當(dāng)然這個(gè)答案有時(shí)我們自己也可能很難給出，那么我們還需要從其他角度來(lái)考量EJB和非EJB之選，例如筆者曾經(jīng)經(jīng)歷一個(gè)大型實(shí)時(shí)娛樂(lè)平臺(tái)社區(qū)系統(tǒng)，從規(guī)模上說(shuō)肯定是大型系統(tǒng)，設(shè)計(jì)目標(biāo)10萬(wàn)人在線(xiàn)，從這個(gè)角度非選用EJB不可！

　　但是，EJB因?yàn)檫€有事務(wù)機(jī)制，雖然應(yīng)用程序可以選擇失效EJB事務(wù)，但是EJB容器設(shè)計(jì)因?yàn)榭紤]了事務(wù)，所以在其內(nèi)核上總是會(huì)顯得臃腫，是一種累贅，這也是一種重量表示，不需要的東西存在肯定會(huì)影響效率，那么難道我不能根據(jù)我的需求，對(duì)EJB整體包括EJB容器進(jìn)行可配置式的切割？也就是說(shuō)，我上面這個(gè)案例只需要EJB的分布式計(jì)算功能，其他的功能我都拆除，只剩余我需要的功能能運(yùn)行就可以了，輕裝上陣。

　　可惜，這種任意切割，應(yīng)需而定的目標(biāo)在EJB3標(biāo)準(zhǔn)還沒(méi)有被重視，所幸的是，Ioc/AOP技術(shù)為這種目標(biāo)實(shí)現(xiàn)提供了實(shí)現(xiàn)可能，但是，只有Ioc/AOP還是不夠，特別是看Ioc的范圍，如果你只把應(yīng)用系統(tǒng)組件納入Ioc管理時(shí)，自由解耦只屬于應(yīng)用系統(tǒng)，我上面案例的目標(biāo)還是無(wú)法達(dá)到，當(dāng)你把框架本身組件也納入Ioc管理時(shí)，任意切割，應(yīng)需而定的目標(biāo)才真正實(shí)現(xiàn)。

　　Spring和EJB3屬于“只把應(yīng)用系統(tǒng)組件納入Ioc管理”，這從JBoss 4.0版本可以看出；那什么框架會(huì)把框架本身組件也納入Ioc管理呢？Apache的Hivemind和筆者開(kāi)發(fā)的Jdon框架。

　　什么樣的組件可以被納入Ioc管理呢？POJO組件，POJO這個(gè)概念其實(shí)當(dāng)初是針對(duì)EJB缺點(diǎn)而推出，EJB要求應(yīng)用系統(tǒng)的組件必須繼承或依賴(lài)EJB容器，這樣使得調(diào)試變的不方便，但是后來(lái)，POJO的概念已經(jīng)不只最初這些概念，POJO代表那種與周?chē)耆撾x關(guān)系、自由自在的Object了，如果應(yīng)用系統(tǒng)的Model或者Service都是POJO，意味著你的應(yīng)用系統(tǒng)不依賴(lài)任何其他系統(tǒng)，解耦性靈活性高。

　　POJO是因?yàn)镋JB而提出的，當(dāng)EJB自己傾向POJO時(shí)，大家都在宣稱(chēng)自己是POJO時(shí)，POJO概念就沒(méi)有立足點(diǎn)了，這也是Java領(lǐng)域哭笑不得的現(xiàn)象，但是我個(gè)人更傾向把非EJB的JavaBeans組件通稱(chēng)為POJO。

　　Hivemind的Ioc依賴(lài)注射部分功能和Jdon框架非常類(lèi)似，當(dāng)上百個(gè)POJO組件配置時(shí)，完全不必指定它們之間的依賴(lài)關(guān)系；你可以將自己應(yīng)用程序的組件注冊(cè)到Registry中，這樣Hivemind將幫助你啟動(dòng)這些組件，正如你在Jdon框架中將你的組件寫(xiě)入mycontainer.xml中，Jdon框架也將自動(dòng)啟動(dòng)你這些組件，并解決它們之間的互相調(diào)用，包括和框架本身組件互動(dòng)。

　　HiveMind和Jdon框架定義的POJO Service有如下特點(diǎn)：

　　不象EJB那樣缺乏本地透明化(location transparency)概念，這些POJO Service總是能定位到同樣一個(gè)JVM；也不象基于XML的Web服務(wù)web services那樣沒(méi)有語(yǔ)言透明(language transparency)概念，這些POJO Service總是可以被一組Java接口來(lái)概括替代(通過(guò)調(diào)用Java interface來(lái)替代調(diào)用這些具體Service)；當(dāng)然，更不會(huì)類(lèi)似JMX或Jini，不能進(jìn)行service的熱裝載（ hot-loading）。

　　注意：當(dāng)Ioc/AOP提供高度靈活的同時(shí)，已經(jīng)有初學(xué)者開(kāi)始抱怨Spring的過(guò)分靈活，那么比Spring在組件上更靈活的Jdon框架只能算是一種追求極端，它不一定構(gòu)成你進(jìn)行架構(gòu)選擇的主要依據(jù)！

　　上面這些討論只是表明在靈活性（解耦性/透明性）這條需求道路上深究下去的選擇，你自己的應(yīng)用系統(tǒng)需求會(huì)產(chǎn)生各種不同的要求，有些要求甚至是極致的，這種偏向程度就成為你架構(gòu)選擇的目標(biāo)，如果你的這種極致要求在目前Java世界里還沒(méi)有可選框架時(shí)，那么你就要?jiǎng)邮肿约鹤隽耍@也說(shuō)明什么時(shí)候你開(kāi)始自己做框架（如Jdon框架），雖然在大多數(shù)情況下我們是不必要自己發(fā)明輪子的。

快速構(gòu)建性

　　前面是從靈活性和定制性這個(gè)角度討論架構(gòu)選擇目標(biāo)，但是在一般情況下，我們還是從上手難易、開(kāi)發(fā)效率這個(gè)角度來(lái)進(jìn)行架構(gòu)選擇，從這個(gè)角度來(lái)說(shuō)，就是需要我們將選用的框架盡可能的多幫助我們實(shí)現(xiàn)一些功能，但這又是和使用難易是矛盾的，因此有個(gè)取舍問(wèn)題，取舍有個(gè)準(zhǔn)則：這個(gè)框架盡量能提供越多功能；盡量需要我們少寫(xiě)代碼，甚至不寫(xiě)代碼（使用XML配置），少動(dòng)腦筋。

　　關(guān)于XML配置這里也涉及難易問(wèn)題，XML配置語(yǔ)法不能太復(fù)雜，有太多小開(kāi)關(guān)Switch也增加學(xué)習(xí)成本。

　　從這個(gè)角度看，EJB無(wú)論是EJB2或EJB3提供的功能是最齊全的，但是XML配置開(kāi)關(guān)太多 ，Spring屬于中等，組件XML配置不算簡(jiǎn)單，但是因?yàn)橛胁簧賁truts+Spring+Hibernate之類(lèi)現(xiàn)成開(kāi)源代碼可供參考，因此學(xué)習(xí)起來(lái)難度也不大，Spring越來(lái)越象一個(gè)J2EE API（注意，JDK是J2SE API） ，Spring除不能提供分布式計(jì)算外，也因?yàn)檫^(guò)分靈活降低了一些開(kāi)發(fā)效率，例如它的組件依賴(lài)關(guān)系一般需要逐步指定，auotwiring功能還沒(méi)有深入骨髓成為核心功能。Ioc容器的革命性?xún)?yōu)點(diǎn)。

　　Spring除了提供組件層功能以外，還有表現(xiàn)層支持Spring MVC；也有持久層實(shí)現(xiàn)的JDBC模板，這樣，整個(gè)J2EE/Java EE系統(tǒng)各個(gè)層次Spring都提供了缺省實(shí)現(xiàn)，在這方面無(wú)疑提高了開(kāi)發(fā)效率，但是Spring提供豐富API目的好像不是為了快速開(kāi)發(fā)，而是為了建立一個(gè)完整的功能齊全的API功能庫(kù)。正如它網(wǎng)頁(yè)上開(kāi)頭文字所述：As the leading full-stack Java/J2EE application framework，注意full-stack（完整齊全）是它突出的名詞。

　　那么，還有另外一個(gè)空白，就是以開(kāi)發(fā)效率為主要考慮，這類(lèi)框架除了必須考慮足夠靈活性和豐富功能以外，宗旨是為了在一般缺省情況下快速完成一個(gè)J2EE/Java EE系統(tǒng)，這非常類(lèi)似MDA工具了，但是一個(gè)完全喪失靈活性和定制性的MDA工具也不是我們歡迎的。

　　Jdon框架的發(fā)展目標(biāo)是為了填補(bǔ)這個(gè)空白，相信也會(huì)越來(lái)越多框架向這個(gè)目標(biāo)邁進(jìn)，當(dāng)然不可否認(rèn)，Spring也可能調(diào)轉(zhuǎn)槍頭走入這個(gè)領(lǐng)域，EJB2/EJB3正依靠JBuilder等這樣商業(yè)化開(kāi)發(fā)工具向這個(gè)領(lǐng)域靠攏，這個(gè)發(fā)展方向?qū)嶋H是4GL RAD Tools。

　　很多人在快速構(gòu)建方面也很早進(jìn)行了探索，涌現(xiàn)出各種工具：如何構(gòu)建一個(gè)快速業(yè)務(wù)構(gòu)件平臺(tái)？ 但是如何把快速構(gòu)建和構(gòu)件（組件）靈活性有機(jī)結(jié)合在一起？它是考驗(yàn)一個(gè)業(yè)務(wù)構(gòu)件（業(yè)務(wù)組件）平臺(tái)好壞的準(zhǔn)則。有些構(gòu)件平臺(tái)雖然開(kāi)發(fā)迅速，但是對(duì)于特殊情況，可供程序員定制透明操作部分不多，很死，典型的是兩層結(jié)構(gòu)以前的Delphi，開(kāi)發(fā)很快速，但是無(wú)法象J2EE這樣深入到系統(tǒng)各個(gè)層次進(jìn)行定制/維護(hù)/拓展！

業(yè)務(wù)組件框架對(duì)比

EJB2/EJB3 Spring Framework Jdon Framework 靈活性 (松耦合) EJB3比EJB2更具靈活性，EJB3支持應(yīng)用系統(tǒng)POJO 支持應(yīng)用系統(tǒng)POJO，框架基礎(chǔ)功能不能替換 支持應(yīng)用系統(tǒng)POJO，框架本身可分離配置，定制性更強(qiáng) 功能完整性 全面，支持異步JMS 分布式事務(wù) 較為全面。有自己的表現(xiàn)層和持久層模板,可支持異步 基本完整，表現(xiàn)層借助Struts實(shí)現(xiàn)。有自己簡(jiǎn)單的持久層模板 單臺(tái)性能 一般，批量查詢(xún)等大數(shù)據(jù)量業(yè)務(wù)處理須小心，存在本地不透明缺陷。 一般，框架本身組件無(wú)性能提升極致，應(yīng)用程序可配置cache/Pool 好，框架本身組件使用緩存提升性能，應(yīng)用程序可配置cache/Pool，批量查詢(xún)專(zhuān)門(mén)優(yōu)化，適合實(shí)時(shí)性并發(fā)性要求較高應(yīng)用 可伸縮性 可支持多臺(tái)服務(wù)器分布式計(jì)算。 不支持，可依靠EJB實(shí)現(xiàn) 不支持，可依靠EJB實(shí)現(xiàn) 開(kāi)發(fā)效率 學(xué)習(xí)曲線(xiàn)長(zhǎng),導(dǎo)致熟練掌握難。借助商業(yè)開(kāi)發(fā)工具可加快熟練者的開(kāi)發(fā)速度。 較為復(fù)雜，可挑選只適合自己的功能實(shí)現(xiàn)。當(dāng)組件很多時(shí)，需要照顧這些組件之間調(diào)用關(guān)系。 簡(jiǎn)單快速，表現(xiàn)層編碼很少。當(dāng)組件個(gè)數(shù)很多時(shí)，無(wú)需照顧它們之間的調(diào)用關(guān)系 系統(tǒng)規(guī)模 EJB2適合大型系統(tǒng);EJB3適合中大型系統(tǒng) 適合中小型系統(tǒng) 適合小中型系統(tǒng)，建立一個(gè)簡(jiǎn)單的網(wǎng)站系統(tǒng)等，和EJB無(wú)縫結(jié)合，可借助EJB支持中大型系統(tǒng) 重量級(jí)別 重量，正在減肥 輕量偏重，有可能繼續(xù)增肥 最輕量，恪守簡(jiǎn)單快速原則

 

持久層框架

　　持久層框架目前有EJB2/EJB3的實(shí)體Bean、Hibernate和各種JDO產(chǎn)品，當(dāng)然還有直接寫(xiě)SQL語(yǔ)句的JDBC，如iBatis等。

　　持久層框架質(zhì)量好與壞區(qū)分就是是否是O/R Mapping，也就是對(duì)象和關(guān)系數(shù)據(jù)庫(kù)映射，關(guān)系數(shù)據(jù)庫(kù)需要實(shí)現(xiàn)定義好Schema結(jié)構(gòu)；對(duì)象因?yàn)樽侄味兊囊灿幸粋€(gè)自己的結(jié)構(gòu)，如何將對(duì)象數(shù)據(jù)自動(dòng)持久化到數(shù)據(jù)庫(kù)中，首先我們得定義兩者結(jié)構(gòu)的對(duì)應(yīng)，這實(shí)際是數(shù)據(jù)的元數(shù)據(jù)定義。

　　因?yàn)镠iberante/Toplink/JDO這樣O/R Mapping工具幫助你實(shí)現(xiàn)對(duì)象和數(shù)據(jù)庫(kù)轉(zhuǎn)換，克服了對(duì)象和數(shù)據(jù)庫(kù)阻抗現(xiàn)象，O/R Mapping總結(jié) ，所以才使得我們更多的可以對(duì)象方式（從模型Model對(duì)象）來(lái)考慮Java EE/J2EE系統(tǒng)，可以完全放棄以前那種以數(shù)據(jù)庫(kù)為中心的思維方式：數(shù)據(jù)庫(kù)時(shí)代的終結(jié)。

　　所以，是否選用好的持久層框架，取決于你整個(gè)團(tuán)隊(duì)思維是否徹底OO了，是否需要真正OO，當(dāng)然，對(duì)于一些小型項(xiàng)目，有時(shí)我們覺(jué)得直接使用JDBC模板反而更加輕松快捷一點(diǎn)，這也是Spring的JDBC模板/iBatis/Jdon的Jdbc模板存在的理由了。

例如新增一個(gè)數(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興師動(dòng)眾的多個(gè)XML配置和關(guān)系映射思考相比，對(duì)于習(xí)慣SQL語(yǔ)句的程序員反而更加迅速。

　　從以上可以看出，靈活性/快速性/簡(jiǎn)單性/可伸縮性是我們進(jìn)行架構(gòu)選擇的主要幾個(gè)依據(jù)，架構(gòu)選擇實(shí)際就是在這幾個(gè)策略之間做一個(gè)平衡。當(dāng)然，還有一個(gè)非常重要的因素，因?yàn)樗粚儆谀硞€(gè)層次的技術(shù)，性能/緩存是必須和上面因素綜合考慮的因素。

　　因?yàn)樾阅茏畛跏俏覀兪褂糜?jì)算機(jī)的基本原因，別忘記這個(gè)根本。