簡介（DI / CDI基礎）

首先，我認為對此會有一些困惑，但事實是，它們是相同的–不同之處在于用法及其用途。

DI（依賴注入）是通用術語–該功能基本上是在任何應用程序上進行Bean發現和Bean連接過程的功能。 它不僅可以在應用程序中使用它，還可以在單??元測試和模擬中使用它。 當然，那里有很多DI框架，包括：Guice，Seam，Spring（Seam和Spring擴展了DI方案，并建立了自己的框架），EJB 3.x和CDI本身。

另一方面，CDI結合了所有這些技術，并向組件引入了生命周期–這使得DI技術得以統一，從而使新功能的開發變得直截了當且可行。 您可以將Seams生命周期映射與以JPA作為其持久層的Spring MVC結合在一起-這些技術都是單獨創建的，但都與CDI結合使用，應用程序開發人員可以將它們結合在一起以創建和開發JEE應用程序。

我將需要分解主題，因為我肯定會在這里用單詞和字母讓每個人感到無聊，所以：

DI / CDI基礎

基本注射

資格賽，范圍

DI / CDI高級

我將為每個人創建單獨的帖子！

讓我們開始！

SPI（服務編程接口）

它還具有所謂的SPI-顯然是與API一起提供的功能集，但完全具有不同的用途。

• API是您為實現目標而調用并使用的類/接口/方法/…的描述。
• SPI是您為實現目標而擴展和實現的類/接口/方法/…的描述。

使用SPI，您實際上可以擴展JEE6以創建自己的不同框架，從而展示可移植性和可擴展性。 （ 但我稍后會介紹 ）。

為什么選擇CEE for JEE6？

CDI已經出現在JEE5（J2EE）中，并取得了巨大的成功。 它的方法使很多新開發受益，最終簡化了整個開發過程。 在JEE6中改進CDI的幾個原因。

• JEE5確實支持資源注入，但是它仍然缺乏通用的依賴關系–它僅支持@ EJB，@ PersistenceContext，@ PersistenceUnit，@ Resources）–當然，除了Spring引入了用于管理bean生命周期的不同注釋外
• 非基于類型的注入（弱）–字符串名稱和XML注入確實很脆弱。 改進基于類型的注入通常可以實現更好的工具。

術語

CDI –上下文和依賴注入

焊接

• JSR 299參考實現–參考實現是用于擴展JSR特定實現的SPI。
• 為Servlet容器提供擴展的CDI支持。
• 擴展編寫器的CDI增強功能。
• CDI和Java EE的Maven原型（我喜歡maven！）。

CDI主題：松耦合和強類型

松散耦合僅表示對象與使用或當前使用的對象在松散地獨立。 CDI引入了用于解耦的新功能，例如限定符 ，增強了攔截器 ， 修飾器 ，消息生成器 ， 使用者及其底層事件機制。 將深入探討有關CDI高級主題的每個示例。

強大的輸入 -只是意味著通過讓容器創建特定的名稱并將其映射到對象來嚴格聲明bean。 這樣就不需要對字符串進行基于字符串的命名，幾乎不需要鑄造，因為鑄造是由容器完成的（利用限定符）。

豆（什么？）

從技術上講，您擁有多種形式的Bean：JSF Bean，EJB Bean，Spring，Seam，Guice CDI，實體Bean等，但最終，Bean只是具有特殊定義的POJO（由Managed Bean 1.0定義） – Java EE6中制定的規范。 這意味著任何POJO都可以是任何類型的bean，只要它符合規范標準即可–從而進一步簡化了聲明和開發過程。 容器負責管理POJO，并通過提供/引入常見的基本服務來增加對它的支持，例如：

• 生命周期管理（@ PostConstruct，@ PreDestory）
• 注入資源（@Resource）
• 攔截器（@ Interceptors，@ ArounInvoke）

@javax.annotation.ManagedBean public class MyPojo {@Resource // Resource injection private Datasource ds;@PostConstruct // Life-cycle private void init() {.... } @Interceptors(LoggingInterceptor.class)public void myMethod() {...} }

考慮到這一點， EJB ， REST和CDI bean呢？

• EJB bean服務–托管bean，具有公共服務（上述）并支持事務，安全性，線程安全性和持久性。
• REST bean服務–具有HTTP支持的托管bean
• CDI bean –具有生命周期的托管bean支持：
  • 自動發現

確切地說，Manage Bean最終是針對特定用途而擴展的SPI。 EJB，Rest，實體Bean都是托管Bean，但是容器提供了其他服務。 因此，如果您使用@Stateless或@Stateful批注定義POJO，則容器會自動檢測到它是EJB bean，并且需要特定于容器的支持，例如事務，安全性，線程安全性，擴展等。

package mypackage; import javax.ejb.Stateless;@Stateless public class GreetingBean {public String greet(String name){return "Hello " + name;} }

一個簡單的POJO類就用一個手指（實際上是敲入）就變成了一個Stateless bean，從而產生了一個@Stateless代碼。 與先驗3.x上定義EJB的方式不同（這很痛苦）。

從此處下載示例（以上）： 單擊我

自動Bean發現

CDI容器是負責如何發現Bean的容器，但是它是如何做到的？

它首先掃描包含應用程序和容器檔案的類路徑。

它嘗試掃描類路徑，并查看標記為發現的POJO（即托管Bean）。 您可以考慮將其放入一個池中，并且當另一個Managed Bean通過注入對其進行調用時可以隨時使用（有關下一個博客主題的更多信息）

然后，它檢測到bean.xml（或任何上下文xml文件定義）的存在。

對于Spring愛好者來說，這很像一個applicationContext.xml（至少是約定，但很松散）–您將XML傳遞到contextConfiguration偵聽器（直通參數）上，Spring CDI Container會自動在其中標記對象（beans）以便發現–當然，您需要定義掃描機制（組件掃描）。

最終，引入DI / CDI是為了簡化開發過程，統一技術以及整體以產生更強大，可擴展的應用程序。 讓所有容器按照標記Bean的公共服務的方式工作，這使開發人員的任務更加輕松，而且比避免以前的框架導致的陷阱更重要。 SPI –實際上是改進的定義，它允許實際的JEE6框架可擴展，從而創造了更加動態的特性–業務應用程序架構師現在可以設計自己的框架和約定。 為自己的規則放置更多特定于業務的設計或注釋，并提供企業應用程序始終需要的健壯性和靈活性。

下一主題： 基本進樣 –我不想將所有內容放到一個帖子中，因此我將讓您先吸收它并檢查我創建的樣本。 從現在開始，我將詳細介紹DI和CDI的示例。

參考： DI / CDI – JCG合作伙伴 Alvin Reyes在Alvin“ Jay” Reyes博客博客上的基礎知識 。

翻譯自: https://www.javacodegeeks.com/2013/08/di-cdi-basics.html

總結

以上是生活随笔為你收集整理的DI / CDI –基础的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。