[[274718]]

Spring 及其優(yōu)點(diǎn)

大部分項(xiàng)目都少不了spring的身影，為什么大家對(duì)他如此青睞，而且對(duì)他的追捧絲毫沒有減退之勢(shì)呢?

Spring是什么：

Spring是一個(gè)輕量級(jí)的DI和AOP容器框架。

說它輕量級(jí)有一大部分原因是相對(duì)與EJB的(雖然本人從沒有接觸過EJB的應(yīng)用)，重要的是，Spring是非侵入式的，基于spring開發(fā)的應(yīng)用一般不依賴于spring的類。

DI：稱作依賴注入(Dependency Injection),和控制反轉(zhuǎn)一個(gè)概念，具體的講，當(dāng)一個(gè)角色需要另外一個(gè)角色協(xié)助的時(shí)候，在傳統(tǒng)的程序設(shè)計(jì)中，通常有調(diào)用者來創(chuàng)建被調(diào)用者的實(shí)例。但是在spring中創(chuàng)建被調(diào)用者將不再有調(diào)用者完成，因此叫控制反轉(zhuǎn)。創(chuàng)建被調(diào)用對(duì)象有Spring來完成，在容器實(shí)例化對(duì)象的時(shí)候主動(dòng)的將被調(diào)用者(或者說它的依賴對(duì)象)注入給調(diào)用對(duì)象，因此又叫依賴注入。

AOP：Spring對(duì)面向切面編程提供了強(qiáng)有力的支持，通過它讓我們將業(yè)務(wù)邏輯從應(yīng)用服務(wù)(如事務(wù)管理)中分離出來，實(shí)現(xiàn)了高內(nèi)聚開發(fā)，應(yīng)用對(duì)象只關(guān)注業(yè)務(wù)邏輯，不再負(fù)責(zé)其它系統(tǒng)問題(如日志、事務(wù)等)。Spring支持用戶自定義切面。

面向切面編程是面向?qū)ο缶幊痰挠辛ρa(bǔ)充。面向?qū)ο缶幊虒⒊绦蚍殖筛鱾€(gè)層次的對(duì)象，面向切面的程序?qū)⑦\(yùn)行過程分解成各個(gè)切面。AOP是從運(yùn)行程序的角度去考慮程序的結(jié)構(gòu)，提取業(yè)務(wù)處理過程的切面，OOP是靜態(tài)的抽象，AOP是動(dòng)態(tài)的抽象，是對(duì)應(yīng)用執(zhí)行過程的步驟進(jìn)行抽象，從而獲得步驟之間的邏輯劃分。

容器：Spring是個(gè)容器，因?yàn)樗⑶夜芾響?yīng)用對(duì)象的生命周期和配置。如對(duì)象的創(chuàng)建、銷毀、回調(diào)等。

框架：Spring作為一個(gè)框架，提供了一些基礎(chǔ)功能，(如事務(wù)管理，持久層集成等)，使開發(fā)人員更專注于開發(fā)應(yīng)用邏輯。

看完了Spring是什么，再來看看Spring有哪些優(yōu)點(diǎn)

1.使用Spring的IOC容器，將對(duì)象之間的依賴關(guān)系交給Spring，降低組件之間的耦合性，讓我們更專注于應(yīng)用邏輯

2.可以提供眾多服務(wù)，事務(wù)管理，WS等。

3.AOP的很好支持，方便面向切面編程。

4.對(duì)主流的框架提供了很好的集成支持，如hibernate,Struts2,JPA等

5.Spring DI機(jī)制降低了業(yè)務(wù)對(duì)象替換的復(fù)雜性。

6.Spring屬于低侵入，代碼污染極低。

7.Spring的高度可開放性，并不強(qiáng)制依賴于Spring，開發(fā)者可以自由選擇Spring部分或全部

 

Struts2的優(yōu)點(diǎn)

Struts2 是一個(gè)相當(dāng)強(qiáng)大的Java Web開源框架，是一個(gè)基于POJO的Action的MVC Web框架。它基于當(dāng)年的Webwork和XWork框架，繼承其優(yōu)點(diǎn)，同時(shí)做了相當(dāng)?shù)母倪M(jìn)。Struts2現(xiàn)在在Java Web開發(fā)界的地位可以說是大紅大紫，從開發(fā)人員的角度來分析，Struts2之所以能夠如此的深入開發(fā)人員之心，與其優(yōu)良的設(shè)計(jì)是分不開的。

1、Struts2基于MVC架構(gòu),框架結(jié)構(gòu)清晰，開發(fā)流程一目了然，開發(fā)人員可以很好的掌控開發(fā)的過程。

我在項(xiàng)目開發(fā)過程中，一個(gè)具體的功能的開發(fā)流程是：拿到一個(gè)具體的功能需求文檔和設(shè)計(jì)好的前臺(tái)界面(在開發(fā)中我不負(fù)責(zé)設(shè)計(jì)頁面)，分析需要從前臺(tái)傳遞哪些參數(shù)，確定參數(shù)的變量名稱，在Action中設(shè)置相應(yīng)的變量，這些參數(shù)在前臺(tái)如何顯示，并將頁面上的一些控件適當(dāng)使用Struts2提供的服務(wù)器端控件來代替，編寫Action對(duì)應(yīng)的方法來完成業(yè)務(wù)邏輯，最后，做一些與配置文件相關(guān)的設(shè)置。當(dāng)然實(shí)際的開發(fā)比這個(gè)過程要復(fù)雜，涉及到數(shù)據(jù)庫，驗(yàn)證，異常等處理。但是使用Struts2進(jìn)行開發(fā)，你的關(guān)注點(diǎn)絕大部分是在如何實(shí)現(xiàn)業(yè)務(wù)邏輯上，開發(fā)過程十分清晰明了。

2、使用OGNL進(jìn)行參數(shù)傳遞。

OGNL提供了在Struts2里訪問各種作用域中的數(shù)據(jù)的簡(jiǎn)單方式，你可以方便的獲取Request，Attribute，Application，Session，Parameters中的數(shù)據(jù)。大大簡(jiǎn)化了開發(fā)人員在獲取這些數(shù)據(jù)時(shí)的代碼量。

3、強(qiáng)大的攔截器

Struts2 的攔截器是一個(gè)Action級(jí)別的AOP，Struts2中的許多特性都是通過攔截器來實(shí)現(xiàn)的，例如異常處理，文件上傳，驗(yàn)證等。攔截器是可配置與重用的，可以將一些通用的功能如：登錄驗(yàn)證，權(quán)限驗(yàn)證等置于攔截器中以完成一些Java Web項(xiàng)目中比較通用的功能。在我實(shí)現(xiàn)的的一Web項(xiàng)目中，就是使用Struts2的攔截器來完成了系統(tǒng)中的權(quán)限驗(yàn)證功能。

4、易于測(cè)試

Struts2的Action都是簡(jiǎn)單的POJO，這樣可以方便的對(duì)Struts2的Action編寫測(cè)試用例，大大方便了Java Web項(xiàng)目的測(cè)試。

5、易于擴(kuò)展的插件機(jī)制

在Struts2添加擴(kuò)展是一件愉快而輕松的事情，只需要將所需要的Jar包放到WEB-INF/lib文件夾中，在struts.xml中作一些簡(jiǎn)單的設(shè)置就可以實(shí)現(xiàn)擴(kuò)展。常用的Struts2的擴(kuò)展可以通過這個(gè)鏈接找到：

http://cwiki.apache.org/S2PLUGINS/home.html

6、模塊化

Struts2已經(jīng)把模塊化作為了體系架構(gòu)中的基本思想，可以通過三種方法來將應(yīng)用程序模塊化：

將配置信息拆分成多個(gè)文件

把自包含的應(yīng)用模塊創(chuàng)建為插件

創(chuàng)建新的框架特性，即將與特定應(yīng)用無關(guān)的新功能組織成插件，以添加到多個(gè)應(yīng)用中去。

7、全局結(jié)果與聲明式異常

為應(yīng)用程序添加全局的Result，和在配置文件中對(duì)異常進(jìn)行處理，這樣當(dāng)處理過程中出現(xiàn)指定異常時(shí)，可以跳轉(zhuǎn)到特定頁面，這一功能十分實(shí)用。

 

Spring MVC和Struts2的比較的優(yōu)點(diǎn)

我們用struts2時(shí)采用的傳統(tǒng)的配置文件的方式，并沒有使用傳說中的0配置。spring3 mvc可以認(rèn)為已經(jīng)100%零配置了(除了配置spring mvc-servlet.xml外)。

Spring MVC和Struts2的區(qū)別：

機(jī)制：spring mvc的入口是servlet，而struts2是filter(這里要指出，filter和servlet是不同的。以前認(rèn)為filter是 servlet的一種特殊)，這樣就導(dǎo)致了二者的機(jī)制不同，這里就牽涉到servlet和filter的區(qū)別了。

性能：spring會(huì)稍微比struts快。spring mvc是基于方法的設(shè)計(jì)，而sturts是基于類，每次發(fā)一次請(qǐng)求都會(huì)實(shí)例一個(gè)action，每個(gè)action都會(huì)被注入屬性，而spring基于方法，粒度更細(xì)，但要小心把握像在servlet控制數(shù)據(jù)一樣。spring3 mvc是方法級(jí)別的攔截，攔截到方法后根據(jù)參數(shù)上的注解，把request數(shù)據(jù)注入進(jìn)去，在spring3 mvc中，一個(gè)方法對(duì)應(yīng)一個(gè)request上下文。而struts2框架是類級(jí)別的攔截，每次來了請(qǐng)求就創(chuàng)建一個(gè)Action，然后調(diào)用setter getter方法把request中的數(shù)據(jù)注入;struts2實(shí)際上是通過setter getter方法與request打交道的;struts2中，一個(gè)Action對(duì)象對(duì)應(yīng)一個(gè)request上下文。

參數(shù)傳遞：struts是在接受參數(shù)的時(shí)候，可以用屬性來接受參數(shù)，這就說明參數(shù)是讓多個(gè)方法共享的。

設(shè)計(jì)思想上：struts更加符合oop的編程思想， spring就比較謹(jǐn)慎，在servlet上擴(kuò)展。

intercepter的實(shí)現(xiàn)機(jī)制：struts有以自己的interceptor機(jī)制，spring mvc用的是獨(dú)立的AOP方式。這樣導(dǎo)致struts的配置文件量還是比spring mvc大，雖然struts的配置能繼承，所以我覺得論使用上來講，spring mvc使用更加簡(jiǎn)潔，開發(fā)效率Spring MVC確實(shí)比struts2高。spring mvc是方法級(jí)別的攔截，一個(gè)方法對(duì)應(yīng)一個(gè)request上下文，而方法同時(shí)又跟一個(gè)url對(duì)應(yīng)，所以說從架構(gòu)本身上spring3 mvc就容易實(shí)現(xiàn)restful url。struts2是類級(jí)別的攔截，一個(gè)類對(duì)應(yīng)一個(gè)request上下文;實(shí)現(xiàn)restful url要費(fèi)勁，因?yàn)閟truts2 action的一個(gè)方法可以對(duì)應(yīng)一個(gè)url;而其類屬性卻被所有方法共享，這也就無法用注解或其他方式標(biāo)識(shí)其所屬方法了。spring3 mvc的方法之間基本上獨(dú)立的，獨(dú)享request response數(shù)據(jù)，請(qǐng)求數(shù)據(jù)通過參數(shù)獲取，處理結(jié)果通過ModelMap交回給框架方法之間不共享變量，而struts2搞的就比較亂，雖然方法之間也是獨(dú)立的，但其所有Action變量是共享的，這不會(huì)影響程序運(yùn)行，卻給我們編碼，讀程序時(shí)帶來麻煩。

另外，spring3 mvc的驗(yàn)證也是一個(gè)亮點(diǎn)，支持JSR303，處理ajax的請(qǐng)求更是方便，只需一個(gè)注解@ResponseBody ，然后直接返回響應(yīng)文本即可。送上一段代碼：

[java] view plain copy

在CODE上查看代碼片派生到我的代碼片

@RequestMapping(value=“/whitelists”)  
 public String index(ModelMap map) {  
 Account account = accountManager.getByDigitId(SecurityContextHolder.get().getDigitId());  
 List groupList = groupManager.findAllGroup(account.getId());  
 map.put(“account”, account);  
 map.put(“groupList”, groupList);  
 return “/group/group-index”;  
 }  
 // @ResponseBody ajax響應(yīng)，處理Ajax請(qǐng)求也很方便  
 @RequestMapping(value=“/whitelist/{whiteListId}/del”)  
 @ResponseBody  
 public String delete(@PathVariable Integer whiteListId) {  
 whiteListManager.deleteWhiteList(whiteListId);  
 return “success”;  
 }  

struts1與struts2本質(zhì)區(qū)別

1 在Action實(shí)現(xiàn)類方面的對(duì)比：Struts 1要求Action類繼續(xù)一個(gè)抽象基類;Struts 1的一個(gè)具體問題是使用抽象類編程而不是接口。Struts 2 Action類可以實(shí)現(xiàn)一個(gè)Action接口，也可以實(shí)現(xiàn)其他接口，使可選和定制的服務(wù)成為可能。Struts 2提供一個(gè)ActionSupport基類去實(shí)現(xiàn)常用的接口。即使Action接口不是必須實(shí)現(xiàn)的，只有一個(gè)包含execute方法的POJO類都可以用 作Struts 2的Action。

2 線程模式方面的對(duì)比：Struts 1 Action是單例模式并且必須是線程安全的，因?yàn)閮H有Action的一個(gè)實(shí)例來處理所有的請(qǐng)求。單例策略限制了Struts 1 Action能做的事，并且要在開發(fā)時(shí)非凡小心。Action資源必須是線程安全的或同步的;Struts 2 Action對(duì)象為每一個(gè)請(qǐng)求產(chǎn)生一個(gè)實(shí)例，因此沒有線程安全問題。

3 Servlet依靠方面的對(duì)比：Struts 1 Action依靠于Servlet API，因?yàn)镾truts 1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts 2 Action不再依靠于Serzvlet API，從而答應(yīng)Action脫離Web容器運(yùn)行，從而降低了測(cè)試Action的難度。 當(dāng)然，假如Action需要直接訪問HttpServletRequest和HttpServletResponse參數(shù)，Struts 2 Action仍然可以訪問它們。但是，大部分時(shí)候，Action都無需直接訪問HttpServetRequest和 HttpServletResponse，從而給開發(fā)者更多靈活的選擇。

4 可測(cè)性方面的對(duì)比：測(cè)試Struts 1 Action的一個(gè)主要問題是execute方法依靠于Servlet API，這使得Action的測(cè)試要依靠于Web容器。為了脫離Web容器測(cè)試Struts 1的Action，必須借助于第三方擴(kuò)展：Struts TestCase，該擴(kuò)展下包含了系列的Mock對(duì)象(模擬了HttpServetRequest和HttpServletResponse對(duì)象)，從而 可以脫離Web容器測(cè)試Struts 1的Action類。Struts 2 Action可以通過初始化、設(shè)置屬性、調(diào)用方法來測(cè)試。

5 封裝請(qǐng)求參數(shù)的對(duì)比：Struts 1使用ActionForm對(duì)象封裝用戶的請(qǐng)求參數(shù)，所有的ActionForm必須繼續(xù)一個(gè)基類：ActionForm。普通的JavaBean不能用 作ActionForm，因此，開發(fā)者必須創(chuàng)建大量的ActionForm類封裝用戶請(qǐng)求參數(shù)。雖然Struts 1提供了動(dòng)態(tài)ActionForm來簡(jiǎn)化ActionForm的開發(fā)，但依然需要在配置文件中定義ActionForm;Struts 2直接使用Action屬性來封裝用戶請(qǐng)求屬性，避免了開發(fā)者需要大量開發(fā)ActionForm類的煩瑣，實(shí)際上，這些屬性還可以是包含子屬性的Rich 對(duì)象類型。假如開發(fā)者依然懷念Struts 1 ActionForm的模式，Struts 2提供了ModelDriven模式，可以讓開發(fā)者使用單獨(dú)的Model對(duì)象來封裝用戶請(qǐng)求參數(shù)，但該Model對(duì)象無需繼續(xù)任何Struts 2基類，是一個(gè)POJO，從而降低了代碼污染。

6 表達(dá)式語言方面的對(duì)比：Struts 1整合了JSTL，因此可以使用JSTL表達(dá)式語言。這種表達(dá)式語言有基本對(duì)象圖遍歷，但在對(duì)集合和索引屬性的支持上則功能不強(qiáng);Struts 2可以使用JSTL，但它整合了一種更強(qiáng)大和靈活的表達(dá)式語言：OGNL(Object Graph Notation Language)，因此，Struts 2下的表達(dá)式語言功能更加強(qiáng)大。

7 綁定值到視圖的對(duì)比：Struts 1使用標(biāo)準(zhǔn)JSP機(jī)制把對(duì)象綁定到視圖頁面;Struts 2使用“ValueStack”技術(shù)，使標(biāo)簽庫能夠訪問值，而不需要把對(duì)象和視圖頁面綁定在一起。

8 類型轉(zhuǎn)換的對(duì)比：Struts 1 ActionForm 屬性通常都是String類型。Struts 1使用Commons-Beanutils進(jìn)行類型轉(zhuǎn)換，每個(gè)類一個(gè)轉(zhuǎn)換器，轉(zhuǎn)換器是不可配置的;Struts 2使用OGNL進(jìn)行類型轉(zhuǎn)換，支持基本數(shù)據(jù)類型和常用對(duì)象之間的轉(zhuǎn)換。

9 數(shù)據(jù)校驗(yàn)的對(duì)比：Struts 1支持在ActionForm重寫validate方法中手動(dòng)校驗(yàn)，或者通過整合Commons alidator框架來完成數(shù)據(jù)校驗(yàn)。Struts 2支持通過重寫validate方法進(jìn)行校驗(yàn)，也支持整合XWork校驗(yàn)框架進(jìn)行校驗(yàn)。

10 Action執(zhí)行控制的對(duì)比：Struts 1支持每一個(gè)模塊對(duì)應(yīng)一個(gè)請(qǐng)求處理(即生命周期的概念)，但是模塊中的所有Action必須共享相同的生命周期。Struts 2支持通過攔截器堆棧(Interceptor Stacks)為每一個(gè)Action創(chuàng)建不同的生命周期。開發(fā)者可以根據(jù)需要?jiǎng)?chuàng)建相應(yīng)堆棧，從而和不同的Action一起使用。

Hibernate優(yōu)點(diǎn)

(1) 對(duì)象/關(guān)系數(shù)據(jù)庫映射(ORM)

它使用時(shí)只需要操縱對(duì)象，使開發(fā)更對(duì)象化，拋棄了數(shù)據(jù)庫中心的思想，完全的面向?qū)ο笏枷?/p>

(2) 透明持久化(persistent)

帶有持久化狀態(tài)的、具有業(yè)務(wù)功能的單線程對(duì)象，此對(duì)象生存期很短。這些對(duì)象可能是普通的JavaBeans/POJO，這個(gè)對(duì)象沒有實(shí)現(xiàn)第三方框架 或者接口，唯一特殊的是他們正與(僅僅一個(gè))Session相關(guān)聯(lián)。一旦這個(gè)Session被關(guān)閉，這些對(duì)象就會(huì)脫離持久化狀態(tài)，這樣就可被應(yīng)用程序的任 何層自由使用。(例如，用作跟表示層打交道的數(shù)據(jù)傳輸對(duì)象。)

(3) 事務(wù)Transaction(org.hibernate.Transaction)

應(yīng)用程序用來指定原子操作單元范圍的對(duì)象，它是單線程的，生命周期很短。它通過抽象將應(yīng)用從底層具體的JDBC、JTA以及CORBA事務(wù)隔離 開。某些情況下，一個(gè)Session之內(nèi)可能包含多個(gè)Transaction對(duì)象。盡管是否使用該對(duì)象是可選的，但無論是使用底層的API還是使用 Transaction對(duì)象，事務(wù)邊界的開啟與關(guān)閉是必不可少的。

(4) 它沒有侵入性，即所謂的輕量級(jí)框架

(5) 移植性會(huì)很好

(6) 緩存機(jī)制，提供一級(jí)緩存和二級(jí)緩存

(7) 簡(jiǎn)潔的HQL編程

Hibernate缺點(diǎn)

(1) Hibernate在批量數(shù)據(jù)處理時(shí)有弱勢(shì)

(2) 針對(duì)單一對(duì)象簡(jiǎn)單的增刪查改，適合于Hibernate,而對(duì)于批量的修改，刪除，不適合用Hibernate,這也是OR框架的弱點(diǎn);要使用數(shù)據(jù)庫的特定優(yōu)化機(jī)制的時(shí)候，不適合用Hibernate

Hibernate和iBATIS 優(yōu)缺點(diǎn)比較

(注意:iBATIS 是MyBATIS的前生，也就是1.0版本)

Hibernate的特點(diǎn)：

Hibernate功能強(qiáng)大，數(shù)據(jù)庫無關(guān)性好，O/R映射能力強(qiáng)， Hibernate對(duì)數(shù)據(jù)庫結(jié)構(gòu)提供了較為完整的封裝，Hibernate的O/R Mapping實(shí)現(xiàn)了POJO 和數(shù)據(jù)庫表之間的映射，以及SQL 的自動(dòng)生成和執(zhí)行。程序員往往只需定義好了POJO 到數(shù)據(jù)庫表的映射關(guān)系，即可通過Hibernate 提供的方法完成持久層操作。程序員甚至不需要對(duì)SQL 的熟練掌握， Hibernate/OJB 會(huì)根據(jù)制定的存儲(chǔ)邏輯，自動(dòng)生成對(duì)應(yīng)的SQL 并調(diào)用JDBC 接口加以執(zhí)行。Hibernate的缺點(diǎn)就是學(xué)習(xí)門檻不低，要精通門檻更高，而且怎么設(shè)計(jì)O/R映射，在性能和對(duì)象模型之間如何權(quán)衡取得平衡，以及怎樣用 好Hibernate方面需要你的經(jīng)驗(yàn)和能力都很強(qiáng)才行，但是Hibernate現(xiàn)在已經(jīng)是主流O/R Mapping框架，從文檔的豐富性，產(chǎn)品的完善性，版本的開發(fā)速度都要強(qiáng)于iBATIS。

iBATIS的特點(diǎn)：

iBATIS入門簡(jiǎn)單， 即學(xué)即用，提供了數(shù)據(jù)庫查詢的自動(dòng)對(duì)象綁定功能，而且延續(xù)了很好的SQL使用經(jīng)驗(yàn)，對(duì)于沒有那么高的對(duì)象模型要求的項(xiàng)目來說，相當(dāng)完美。iBATIS的缺 點(diǎn)就是框架還是比較簡(jiǎn)陋，功能尚有缺失，雖然簡(jiǎn)化了數(shù)據(jù)綁定代碼，但是整個(gè)底層數(shù)據(jù)庫查詢實(shí)際還是要自己寫的，工作量也比較大，而且不太容易適應(yīng)快速數(shù)據(jù) 庫修改。當(dāng)系統(tǒng)屬于二次開發(fā),無法對(duì)數(shù)據(jù)庫結(jié)構(gòu)做到控制和修改,那iBATIS的靈活性將比Hibernate更適合。系統(tǒng)數(shù)據(jù)處理量巨大，性能要求極為 苛刻，這往往意味著我們必須通過經(jīng)過高度優(yōu)化的SQL語句(或存儲(chǔ)過程)才能達(dá)到系統(tǒng)性能設(shè)計(jì)指標(biāo)。在這種情況下iBATIS會(huì)有更好的可控性和表現(xiàn)。

對(duì)于實(shí)際的開發(fā)進(jìn)行的比較：

1. iBATIS需要手寫sql語句，也可以生成一部分，Hibernate則基本上可以自動(dòng)生成，偶爾會(huì)寫一些Hql。同樣的需求,iBATIS的工作量比 Hibernate要大很多。類似的，如果涉及到數(shù)據(jù)庫字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。

2. iBatis 可以進(jìn)行細(xì)粒度的優(yōu)化

比 如說我有一個(gè)表，這個(gè)表有幾個(gè)或者幾十個(gè)字段，我需要更新其中的一個(gè)字段，iBatis 很簡(jiǎn)單，執(zhí)行一個(gè)sql UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用 Hibernate 的話就比較麻煩了,缺省的情況下 hibernate 會(huì)更新所有字段。 當(dāng)然我記得 hibernate 有一個(gè)選項(xiàng)可以控制只保存修改過的字段，但是我不太確定這個(gè)功能的負(fù)面效果。

例 如：我需要列出一個(gè)表的部分內(nèi)容，用 iBatis 的時(shí)候，這里面的好處是可以少?gòu)臄?shù)據(jù)庫讀很多數(shù)據(jù)，節(jié)省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE …一般情況下Hibernate 會(huì)把所有的字段都選出來。比 如說有一個(gè)上面表有8個(gè)字段，其中有一兩個(gè)比較大的字段，varchar(255)/text。上面的場(chǎng)景中我為什么要把他們也選出來呢?用 hibernate 的話，你又不能把這兩個(gè)不需要的字段設(shè)置為lazy load，因?yàn)檫€有很多地方需要一次把整個(gè) domain object 加載出來。這個(gè)時(shí)候就能顯現(xiàn)出ibatis 的好處了。如果我需要更新一條記錄(一個(gè)對(duì)象)，如果使用 hibernate，需要現(xiàn)把對(duì)象 select 出來，然后再做 update。這對(duì)數(shù)據(jù)庫來說就是兩條sql。而iBatis只需要一條update的sql就可以了。減少一次與數(shù)據(jù)庫的交互，對(duì)于性能的提升是非常重 要。

3. 開發(fā)方面：

開發(fā)效率上，我覺得兩者應(yīng)該差不多?？删S護(hù)性方面，我 覺得 iBatis 更好一些。因?yàn)?iBatis 的 sql 都保存到單獨(dú)的文件中。而 Hibernate 在有些情況下可能會(huì)在 java 代碼中保sql/hql。相對(duì)Hibernate“O/R”而言，iBATIS 是一種“Sql Mapping”的ORM實(shí)現(xiàn)。(iBatis 是將sql寫在配置文件中的，而hibernate是自己生成的) 而iBATIS 的著力點(diǎn)，則在于POJO 與SQL之間的映射關(guān)系。也就是說，iBATIS并不會(huì)為程序員在運(yùn)行期自動(dòng)生成SQL 執(zhí)行。具體的SQL 需要程序員編寫，然后通過映射配置文件，將SQL所需的參數(shù)，以及返回的結(jié)果字段映射到指定POJO。使用iBATIS 提供的ORM機(jī)制，對(duì)業(yè)務(wù)邏輯實(shí)現(xiàn)人員而言，面對(duì)的是純粹的Java對(duì)象，這一層與通過Hibernate 實(shí)現(xiàn)ORM 而言基本一致，而對(duì)于具體的數(shù)據(jù)操作，Hibernate會(huì)自動(dòng)生成SQL 語句，而iBATIS 則要求開發(fā)者編寫具體的SQL 語句。相對(duì)Hibernate而言，iBATIS 以SQL開發(fā)的工作量和數(shù)據(jù)庫移植性上的讓步，為系統(tǒng)設(shè)計(jì)提供了更大的自由空間。

4. 運(yùn)行效率

在不考慮 cache 的情況下，iBatis 應(yīng)該會(huì)比hibernate 快一些或者很多。

Spring 框架的優(yōu)缺點(diǎn)

Spring的優(yōu)勢(shì)不言而喻：

1. 提供了一種管理對(duì)象的方法，可以把中間層對(duì)象有效地組織起來。一個(gè)完美的框架“黏合劑”。

2. 采用了分層結(jié)構(gòu)，可以增量引入到項(xiàng)目中。

3. 有利于面向接口編程習(xí)慣的養(yǎng)成。

4. 目的之一是為了寫出易于測(cè)試的代碼。

5. 非侵入性，應(yīng)用程序?qū)pring API的依賴可以減至最小限度。

6. 一致的數(shù)據(jù)訪問介面。

6. 一個(gè)輕量級(jí)的架構(gòu)解決方案

缺點(diǎn)也顯而易見

1. 中斷了應(yīng)用程序的邏輯，使代碼變得不完整，不直觀。此時(shí)單從Source無法完全把握應(yīng)用的所有行為。

2. 將原本應(yīng)該代碼化的邏輯配置化，增加了出錯(cuò)的機(jī)會(huì)以及額外的負(fù)擔(dān)。

3. 時(shí)光倒退，失去了IDE的支持。在目前IDE功能日益強(qiáng)大的時(shí)代，以往代碼重構(gòu)等讓人頭痛的舉動(dòng)越來越容易。而且IDE還提供了諸多強(qiáng)大的輔助功能，使得 編程的門檻降低很多。通常來說，維護(hù)代碼要比維護(hù)配置文件，或者配置文件+代碼的混合體要容易的多。

4. 調(diào)試階段不直觀，后期的bug對(duì)應(yīng)階段，不容易判斷問題所在。

經(jīng)典架構(gòu)S(Struts)SH的優(yōu)缺點(diǎn)

Struts、Spring、Hibernate能流行這么多年經(jīng)久不衰，自然有它的道理。J2EE最先出現(xiàn)的時(shí)候，我們一般是采用 JSP+Servlet+JavaBean+EJB的架構(gòu)，尤其是1998年～2000年這段時(shí)間，互聯(lián)網(wǎng)的泡沫從興起到破裂，其波瀾壯闊程度，絲毫不亞 于2008年開始的這次經(jīng)濟(jì)危機(jī)，在那個(gè)年代，是否掌握EJB開發(fā)技術(shù)將直接決定你的薪水能否翻一倍或者幾倍。不過，Spring的作者Rod Johnson在2002年根據(jù)多年經(jīng)驗(yàn)撰寫了《Expert o-ne-on-One J2EE Design and Development》，其后又發(fā)表了著名的《Expert o-ne-on-one J2EE Development without EJB》一書，則徹底地改變了傳統(tǒng)的J2EE一統(tǒng)天下的開發(fā)架構(gòu)，基于Struts+Hibernate+Spring的J2EE架構(gòu)也逐漸得到人們的認(rèn) 可，甚至在大型的項(xiàng)目架構(gòu)中也逐漸開始應(yīng)用。下面我們分別說說Spring、Struts和Hibernate的優(yōu)缺點(diǎn)。

Spring 是一個(gè)開源框架，是為了解決企業(yè)應(yīng)用程序開發(fā)復(fù)雜性而創(chuàng)建的?？蚣艿闹饕獌?yōu)勢(shì)之一就是其分層架構(gòu)，使得每個(gè)層之間和類與類之間的關(guān)系，由原來的強(qiáng)綁定與強(qiáng) 耦合轉(zhuǎn)變?yōu)椴唤壎ê退神詈?，直接面向接口編程，把設(shè)計(jì)與實(shí)現(xiàn)相分離的原則發(fā)揮到極致，對(duì)于單元測(cè)試也產(chǎn)生了很深遠(yuǎn)的影響。在Spring出現(xiàn)之前，如果某 個(gè)模塊沒有完成，做單獨(dú)模塊的單元測(cè)試還是很困難的。Spring同時(shí)也是 J2EE 應(yīng)用程序開發(fā)的集成框架，因?yàn)镴2EE是講究分層理念的，Spring使得J2EE每個(gè)層之間的模塊職能更加清晰。

不過，對(duì)于大型項(xiàng)目的開發(fā)，Spring使得原來難以維護(hù)的類與類之間的強(qiáng)耦合關(guān)系，轉(zhuǎn)變?yōu)楦与y以維護(hù)的XML文件配置，這個(gè)工作量也是非常巨大 的，而且更容易出錯(cuò)。而且，隨著每個(gè)應(yīng)用 模塊的升級(jí)，這些模塊之間的版本，也不會(huì)是同步更新的，對(duì)于同一個(gè)公共組件，有的模塊用的可能是1.0版本，而另 外一個(gè)功能模塊用的可能是2.0版本，可怕的是1.0版本和2.0版本之間，可能還不兼容，Spring對(duì)于這些需求，就無能為力了。所以，有人說 Spring不適合大型項(xiàng)目開發(fā)，也是有一定道理的。最近Spring也加入了OSGI標(biāo)準(zhǔn)的實(shí)現(xiàn)，也是為了解決不同版本之間同時(shí)存在的這些問題。不過， 隨著Spring加入的功能越來越多，Spring也就失去了輕量開源框架的特點(diǎn)，變得越來越笨重。

雖然Spring現(xiàn)在也支持了所謂的免配置，可以通過@Autowired標(biāo)簽自行綁定，還可以通過 設(shè)置自動(dòng)綁定加載所有的Hibernate對(duì)象，但是如果這些上百個(gè)或者數(shù)十個(gè)中的任何一個(gè)Entity對(duì)象加載失敗，則整個(gè)Spring服務(wù)就啟動(dòng)不起 來了，這與難于部署的EJB有啥區(qū)別呢?而且，令人可笑的是，由于使用了@Autowired標(biāo)簽，相當(dāng)一部分開發(fā)人員不再面向接口編程了，對(duì)于 Class A的實(shí)例，美其名曰由Spring自行綁定，接口也好，實(shí)際實(shí)現(xiàn)類也好，就在Spring配置一下就可以了。而Spring最核心的就是面向接口編程和 IOC，沒有了面向接口編程，用一個(gè) A a=new A() 來實(shí)例化一個(gè)Class，有什么不可以呢?少寫了一行代碼，引入了一個(gè)重量級(jí)的Spring，究竟為啥使用Spring呢?

對(duì)于Hibernate的流行，則是由于開發(fā)人員和客戶，對(duì)于Entity EJB(實(shí)體EJB)臃腫的身材及部署的困難，是在極度失望情緒下造成的。既然是輕量級(jí)解決方案，那么分布式就不是可選項(xiàng)，沒有分布式，那么EJB就無用 武之地了。話又說回來了，Rod Johnson前些年就因?yàn)閺?qiáng)調(diào)絕大部分企業(yè)應(yīng)用是不需要分布式的，從而推出了自己輕量級(jí)的Spring解決方案。但是最近一年，隨著云計(jì)算架構(gòu)的興起， 架構(gòu)是否支持分布式，又是必選項(xiàng)了。技術(shù)架構(gòu)的選型，就跟法國(guó)巴黎流行時(shí)裝一樣，今年流行短袖，明年流行下擺，真是典型的十年河?xùn)|，十年河西。所以，像 SOA、云計(jì)算、SaaS、物聯(lián)網(wǎng)這些大名詞，不僅會(huì)給客戶帶來很大的困惑，同樣也會(huì)給程序員、系統(tǒng)分析師、系統(tǒng)架構(gòu)師、技術(shù)總監(jiān)帶來困惑。從肯定到否 定，再到自我否定，真是符合大自然螺旋式上升的發(fā)展規(guī)律。

而對(duì)于Struts，它一經(jīng)推出，幾乎打敗了當(dāng)時(shí)的所有競(jìng)爭(zhēng)對(duì)手。Struts的偉大之處，在于它對(duì)網(wǎng)頁數(shù)據(jù)的動(dòng)態(tài)綁定。雖然數(shù)據(jù)綁定不是一個(gè)新名 詞，微軟在1991年推出Visual Basic1.0的時(shí)候，就創(chuàng)造性地發(fā)明了讓VB程序員又愛又恨的數(shù)據(jù)綁定，但是對(duì)于Web 編程，Struts也還是把數(shù)據(jù)綁定首次應(yīng)用到了Web編程上。它能夠讓人們用Set和Get的形式取得網(wǎng)頁數(shù)據(jù)，而不是單一的黑盒式的 request.getParameter()，從而使得網(wǎng)頁數(shù)據(jù)取值進(jìn)入面向?qū)ο?OO)化時(shí)代。

Struts、Hibernate以及Spring本身都是制作精良的框架，但是對(duì)于自己產(chǎn)品和項(xiàng)目的應(yīng)用，一經(jīng)整合在一起，卻不一定很適用。比如 說，對(duì)于數(shù)據(jù)庫相關(guān)的MIS(管理信息系統(tǒng))系統(tǒng)中，增加、修改、刪除、查詢功能是最基本、最常見、必不可少的。對(duì)于這些最基本的功能，不同的架構(gòu)師，則 會(huì)做出不同的選擇。有的架構(gòu)師，選擇了自動(dòng)生成的理念，做一個(gè)代碼自動(dòng)生成器，設(shè)計(jì)好數(shù)據(jù)庫表結(jié)構(gòu)，單擊一個(gè)腳本，或者用Eclipse插件的形式，做個(gè) 圖形化生成界面，自動(dòng)生成SSH框架，完成數(shù)據(jù)庫的增加、修改、刪除、查詢操作。這么做的好處是數(shù)據(jù)庫修改了，代碼自動(dòng)生成就可以了，使得程序員不用再維 護(hù)這些無聊的代碼。不過缺陷也是致命的，一是隨著Struts、Hibernate、Spring的升級(jí)，這個(gè)工具也不得不跟著升級(jí)，而做這個(gè)工具的程序 員，可能早就離開公司了，后續(xù)版本無法維護(hù);二是如果有的業(yè)務(wù)邏輯跟這些生成的代碼有交叉，數(shù)據(jù)庫變更后，代碼也無法再次生成了。三是公司的系統(tǒng)架構(gòu)，則 被嚴(yán)重限制在SSH架構(gòu)基礎(chǔ)上，再也無法改變。有人會(huì)問：即使限制在這三種架構(gòu)上，有何不好嗎?假設(shè)有客戶問，你的框架支持云計(jì)算嗎?你總不能說”由于 Struts、Hibernate、Spring 不支持云計(jì)算架構(gòu)，所以我也不支持”以此取得客戶諒解吧。因此，依賴于第三方架構(gòu)的產(chǎn)品體系架構(gòu)，隨著時(shí)間的推移，受到的限制會(huì)越來越大。