複製鏈接
請複製以下鏈接發送給好友

Guice

鎖定
Guice是Google開發的一個輕量級,基於Java5(主要運用泛型與註釋特性)的依賴注入框架(IOC)。Guice非常小而且快。Guice是類型安全的,它能夠對構造函數,屬性,方法(包含任意個參數的任意方法,而不僅僅是setter方法)進行注入。Guice採用Java加註解的方式進行託管對象的配置,充分利用IDE編譯器的類型安全檢查功能和自動重構功能,使得配置的更改也是類型安全的。Guice提供模塊對應的抽象module,使得架構和設計的模塊概念產物與代碼中的module類一一對應,更加便利的組織和梳理模塊依賴關係,利於整體應用內部的依賴關係維護,而其他IOC框架是沒有對應物的。此外,藉助privateModule的功能,可以實現模塊接口的明確導出和實現封裝,使得支持多數據源這類需求實現起來異常簡單。
外文名
Guice
特    性
自定義scopes,傳遞依賴等
開發公司
Google
基於系統
Java5

Guice產品特性

Guice還具有一些可選的特性比如:自定義scopes,傳遞依賴,靜態屬性注入,與Spring集成和AOP聯盟方法注入等。
一部分人認為,Guice可以完全替代spring, 因為對於DI組件框架來説, 性能是很重要的, guice比spring快十倍左右, 另外, 也是最重要的一點, 使用spring很容易寫成service locator的風格, 而用guice, 你會很自然的形成DI風格.
甚至説,guice簡單超輕量級的DI框架效率是spring的1.6倍,Spring使用XML使用將類與類之間的關係隔離到xml中,由容器負責注入被調用的對象,而guice將類與類之間的關係隔離到Module中,聲明何處需要注入,由容器根據Module裏的描述,注入被調用的對象,使用Annotation使用支持自定義Annotation標註,對於相同的接口定義的對象引用,為它們標註上不同的自定義Annotation註釋,就可以達到同一個類裏邊的同一個接口的引用,注射給不同的實現,在Module裏用標註做區分,靈活性大大增加。
Guice與Spring的對比
-
Spring
Guice
使用XML
使用將類與類之間的關係隔離到xml中,由容器負責注入被調用的對象,因此叫做依賴注入
不使用xml,將類與類之間的關係隔離到Module中,聲明何處需要注入,由容器根據Module裏的描述,注入被調用的對象。
-
使用
支持自定義Annotation標註,使用Annotation也未必是好事,泛型等新特性也未必是好事,大多的服務器均不支持jdk1.5,wls要9以前才支持,而客户由於價格原因也很少選用wls9的,至少我們做過的項目中都沒有。功能再強,客户不需要,何用?
運行效率
裝載spring配置文件時,需解析xml,效率低,getBean效率也不高,不過使用環境不會涉及到getBean,只有生產環境的時候會用到getBean,在裝載spring應用程序的時候,已經完成全部的注射,所以這個低效率的問題不是問題。
使用Annotation,cglib, 效率高與spring最明顯的一個區別,spring是在裝載spring配置文件的時候把該注入的地方都注入完,而Guice呢,則是在使用的時候去注射,運行效率和靈活性高。
耦合度低,強調類非侵入,以外部化的方式處理依賴關係,類裏邊是很乾淨的,在配置文件裏做文章,對類的依賴性極低。
高,代碼級的標註,DI標記@inject侵入代碼中,耦合到了類層面上來,何止侵入,簡直侵略,代碼耦合了過多guice的東西,大大背離了依賴注入的初衷,對於代碼的可維護性,可讀性均不利
類編寫時
需要編寫xml,配置Bean,配置注入
只需聲明為@inject,等着被注入,
最後在統一的Module裏聲明注入方式
僅支持IOC
否,spring已經涉獵很多部分
是,僅僅是個DI容器
是否易於代碼重構
統一的xml配置入口,更改容易
配置工作是在Module裏進行,和spring異曲同功
支持多種注入方式
構造器,setter方法
Field,構造器,setter方法
靈活性
-
1,如果同一個接口定義的引用需要注入不同的實現,就要編寫不同的Module,煩瑣
2,動態注入
如果你想注射的一個實現,你還未知呢,怎麼辦呢,spring是沒辦法,事先在配置文件裏寫死的,而Guice就可以做到,就是説我想注射的這個對象我還不知道注射給誰呢,是在運行時才能得到的的這個接口的實現,所以這就大大提高了依賴注射的靈活性,動態注射。
與現有框架集成度
1, 高,眾多現有優秀的框架(如struts1.x等)均提供了spring的集成入口,而且spring已經不僅僅是依賴注入,包括眾多方面。
2, Spring也提供了對Hibernate等的集成,可大大簡化開發難度。
3, 提供對於orm,rmi,webservice等等接口眾多,體系龐大。
1,可以與現有框架集成,不過僅僅依靠一個效率稍高的DI,就想取代spring的地位,有點難度。
配置複雜度
在xml中定位類與類之間的關係,難度低
代碼級定位類與類之間的關係,難度稍高

Guice相關例子

借斧子的例子説一説spring與guice的區別。
看下邊的例子:對於不同社會形態下一個人(java對象,調用者)需要一把斧子(java對象,被調用者)。
原始社會時
勞動社會基本沒有分工,需要斧子的人(調用者)只好自己去磨一把斧子,每個人擁有自己的斧子,如果把大家的石斧改為鐵斧,需要每個人都要學會磨鐵斧的本領,工作效率極低。對應Java裏的情形是:java程序裏的調用者new一個被調用者的實例。類耦合度極高,修改維護煩瑣,效率極低。
工業社會時
工廠出現,斧子不再由普通人完成,而由工廠生產,當人們需要斧子的時候,可以到工廠購買斧子,無需關心斧子是怎麼製造出來的,如果廢棄鐵斧為鋼斧,只需改變工廠的製造工藝即可,製作工藝是工廠決定的,工廠生產什麼斧子,工人們就得用什麼斧子。對應的java裏的情形是:Java程序的調用者可以以來簡單工廠創建被調用者,變化點被隔離到了簡單工廠裏,雖然耦合度降低,但是調用者會和工廠耦合,而且需要定位自己的工廠
近代工業社會
工廠蓬勃發展,人們需要什麼斧子,只需要提供一個斧子圖形,商家會按照你提供的圖形將你的斧子訂做好,送上門。對應Java裏的情形:spring的依賴注入
按需要分配社會
信息進入現代化,人們不再去工廠購買斧子,不再拘泥於需要什麼斧子事先畫好什麼樣的圖形,只需要打個電話,描述一下需要什麼類型的斧子,或許想打造一個物美價廉的斧子,商家會根據市場零件的價格,計算出最優製作工藝,打造最適合的斧子送過來,更加信息化,更加人性化。對應Java裏的情形:基於描述的注入,動態的,靈活簡單的注入,如:Guice。對於該不該使用Guice,我想也是仁者見仁,智者見智,就像好多論壇裏動不動有人會在那裏討論到底學Java還是學.net或者是使用eclipse還是Jbuilder的這類無聊話題,適合和滿足項目需求的,又能省工省力簡單的完成工作的,就是最好的。