Guice

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

基本介紹

• 外文名：Guice
• 特性：自定義scopes，傳遞依賴等
• 開發公司：Google
• 基於系統：Java5

特性

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標註，使用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中定位類與類之間的關係,難度低	代碼級定位類與類之間的關係,難度稍高

斧子的例子

借斧子的例子說一說spring與guice的區別。

看下邊的例子：對於不同社會形態下一個人（java對象，調用者）需要一把斧子（java對象，被調用者）。

原始社會時

勞動社會基本沒有分工，需要斧子的人（調用者）只好自己去磨一把斧子，每個人擁有自己的斧子，如果把大家的石斧改為鐵斧，需要每個人都要學會磨鐵斧的本領，工作效率極低。對應Java里的情形是：java程式里的調用者new一個被調用者的實例。類耦合度極高，修改維護煩瑣，效率極低。

工業社會時

工廠出現，斧子不再由普通人完成，而由工廠生產，當人們需要斧子的時候，可以到工廠購買斧子，無需關心斧子是怎么製造出來的，如果廢棄鐵斧為鋼斧，只需改變工廠的製造工藝即可，製作工藝是工廠決定的，工廠生產什麼斧子，工人們就得用什麼斧子。對應的java里的情形是：Java程式的調用者可以以來簡單工廠創建被調用者，變化點被隔離到了簡單工廠里，雖然耦合度降低，但是調用者會和工廠耦合，而且需要定位自己的工廠

近代工業社會

工廠蓬勃發展，人們需要什麼斧子，只需要提供一個斧子圖形，商家會按照你提供的圖形將你的斧子訂做好，送上門。對應Java里的情形：spring的依賴注入

按需要分配社會

信息進入現代化，人們不再去工廠購買斧子，不再拘泥於需要什麼斧子事先畫好什麼樣的圖形，只需要打個電話，描述一下需要什麼類型的斧子，或許想打造一個物美價廉的斧子，商家會根據市場零件的價格，計算出最優製作工藝,打造最適合的斧子送過來，更加信息化，更加人性化。對應Java里的情形：基於描述的注入，動態的，靈活簡單的注入，如：Guice。對於該不該使用Guice,我想也是仁者見仁,智者見智,就像好多論壇里動不動有人會在那裡討論到底學Java還是學.net或者是使用eclipse還是Jbuilder的這類無聊話題,適合和滿足項目需求的,又能省工省力簡單的完成工作的,就是最好的。