Java EE CDI方式的依賴注入方法

時間：2024-10-31 16:53:58 J2EE培訓我要投稿

相關推薦

　　Java EE CDI 主要使用@Inject注解來實現(xiàn)依賴注入，把受管理的bean注入到由容器管理的其它資源中去。在本教程中，我們將會介紹在CDI環(huán)境下幾種不同的可選策略來實現(xiàn)依賴注入。

　　本教程基于如下環(huán)境：

　　JDK 1.7.0.21

　　Weld 1.1.10

　　Weld 是CDI 的參考實現(xiàn)。

　　2. 構(gòu)造器依賴注入

　　public class SomeBean {

　　private final Service service;

　　@Inject

　　public SomeBean(Service service){

　　this.service = service;

　　}

　　當CDI容器在初始化一個SomeBean類型的bean實例時，它將會查找該類的默認構(gòu)造器(無參構(gòu)造器)并用它來創(chuàng)建bean實例。但是有一個例外情況，就是當我們還有一個使用@Inject 進行了注解的構(gòu)造器時，這種情況下，容器會改用有注解的構(gòu)造器而不是無參構(gòu)造器，并且把通過構(gòu)造器參數(shù)傳入的依賴資源注入到bean實例中來。

　　注意: 記住一個類只允許有一個@Inject注解的構(gòu)造器。

　　在上面的例子中，容器將會獲取到一個Service 的實例并把它注入到SomeBean 的注解構(gòu)造器中。

　　3. 字段依賴注入

　　public class SomeBean {

　　@Inject

　　private Service service;

　　}

　　這種情況下，當容器初始化一個 SomeBean類型的bean時，它會把一個正確的Service實例注入給該字段，即使該字段是一個私有字段，并且不需要有任何setter方法。

　　4. 初始化方法依賴注入

　　public class SomeBean {

　　private Service service;

　　@Inject

　　public void setService(Service service) {

　　this.service = service;

　　}

　　這種情況下，當容器初始化一個 SomeBean類型的bean時，它會調(diào)用所有由@Inject注解了的方法，并且通過方法參數(shù)的方式把依賴注入進來。

　　@Any 修飾符

　　為了提供完全松耦合的應用，我們通常把接口注入到受管理的資源中。當我們有多個實現(xiàn)了給定接口的bean時該怎么辦呢?我們可以同時使用@Any修飾符和CDI的Instance接口，來把所有該接口的實現(xiàn)bean都注入進一個受管理的bean中：

　　The @Any qualifier

　　public class SomeBean {

　　@Inject

　　public void listServiceImplementations(

　　@Any Instance serviceList) {

　　for(Service service : serviceList){

　　System.out.println(service.getClass().getCanonicalName());

　　}

　　@Any 修飾符告訴容器，任何可供使用的依賴都適用于該注入點，所以容器會把他們都注入進來。如果我們有接口的多個實現(xiàn)而我們只注入其中的一個 - 并且沒有做任何排除工作 - 那么容器將會抱怨并且無法成功的初始化組件。我們將會在其他教程中介紹依賴排除問題。

　　6.注入到生產(chǎn)者方法中

　　生產(chǎn)者方法的參數(shù)也可以經(jīng)由CDI容器進行注入。請查看Java EE CDI Producer methods tutorial.

　　7. CDI 代理

　　如果我們不涉及CDI代理機制，那么本教程將是不完整的。當我們把一個在不同于@Dependent范圍下創(chuàng)建出來的bean注入到另外一個托管資源時，CDI容器不會注入一個被注入bean的直接引用。

　　CDI 中bean 的范圍請看 Java EE CDI bean scopes

　　為什么CDI使用代理? 因為如果bean的直接引用被注入，將會給被管理的bean造成諸如線程安全或并發(fā)訪問的問題。

　　設想一下一個Session 范圍的 bean被注入到一個Application范圍的bean中去的情形。由于application 范圍的bean在所有客戶端間共享，如果多個客戶端同時訪問一個application 范圍的bean，那么將會存在很高的風險出現(xiàn)這種情況：一個客戶端訪問了其他客戶端正在訪問的session范圍的bean。

　　為了處理這種問題，CDI創(chuàng)造了代理并把代理注入進注入點。由代理負責處理對被注入bean的調(diào)用，并實際去調(diào)用正確的bean實例。

　　CDI創(chuàng)建的代理繼承自被注入bean的類型。設想一下下面的情形：

　　Application 和 Session 范圍的 bean

　　@SessionScoped

　　public class Service {

　　public void doWork() {

　　System.out.println("Working...");

　　}

　　@ApplicationScoped

　　public class SomeBean {

　　@Inject

　　private Service service;

　　public void test(){

　　service.doWork();

　　}

　　CDI將把一個session范圍的bean的代理注入進一個application范圍的bean中去。每一次對session范圍bean的調(diào)用，都將通過代理進行，代理會把調(diào)用重定向到正確的session范圍bean的實例，那個從屬于正確的HTTP request session的bean。

　　CDI創(chuàng)建代理是通過繼承原來bean的類，并重寫所有非私有方法。一個簡單的典型的代理的例子可以像下面這樣：

　　CDI 代理示例

　　ublic class Service$Proxy$_$$_WeldClientProxy

　　extends Service {

　　@Override

　　public void doWork() {

　　Service instance = // ... resolve bean instance

　　instance.doWork();

　　}

　　由于CDI代理通過繼承bean的類來創(chuàng)建，所以當我們討論非依賴性bean范圍的時候，你應當明白CDI有如下一些限制：

　　CDI 不能注入原始類型

　　bean的類必須有一個非私有的默認構(gòu)造器