@SessionScoped (CDI) 和 @Stateful (Java EE) 之間的區別

Question

我了解到 CDI Beans 可用於不同的基於 Web 應用程序的范圍（僅在那里，對吧？）。 例如：@RequestScoped、@SessionScoped 等。 @SessionScoped 通過完整的瀏覽器會話將數據保存在托管 bean 中。 這在邏輯上聽起來很安靜，因為注釋名稱描述了它的作用。 但是 - 現在我仔細研究了 EJB 會話 bean。 到目前為止，我知道，這樣的一個狀態可能具有以下三種狀態之一：@Stateless、@Stateful 和 @Singleton。 對我來說，這些和 CDI bean 的注釋之間似乎有直接的可比性：@RequestScoped --> @Stateless、@SessionScoped --> @Stateful、@ApplicationScoped --> @Singleton。 但是由於我正在研究一些示例，我發現了一個包含 @Stateful 和 @SessionScoped 注釋的 bean。 我尋找了解釋 - 但我沒有找到任何可以理解的答案。 那么，究竟有什么區別呢？ 為什么我必須同時使用這兩個注釋？ 謝謝你。

Answer 1

CDI Beans 可用於不同的基於 Web 應用程序的范圍（僅在那里，對吧？）。

錯誤的。 CDI bean 可以在您想要的任何地方使用 - DB 連接/通信、業務邏輯、基於事件的編程，甚至在 Java SE 中（焊接，CDI 的參考實現，現在也提供了）。 但是，特別是@SessionScoped bean 在 HTTP 會話中比其他任何地方都更有意義。 但是您仍然可以將會話想象（和使用）作為具有標記開始和結束的給定時間段。 在這些邊界內，會話存在 - 不需要是 HTTP 會話，但它是最明顯的會話。

這些與 CDI bean 的注釋之間的直接可比性：@RequestScoped --> @Stateless、@SessionScoped --> @Stateful、@ApplicationScoped --> @Singleton。

又錯了。 EJB 僅與 Web 通信相關聯，而 CDI 則不然。 同樣基於您選擇的注釋，您還可以選擇一個容器 (CDI/EJB)，它將負責該 bean。 CDI 集成了所有 EJB bean（創建一個代理並使它“看起來像”一個 CDI bean - 允許您在 EJB bean 中使用 CDI 的東西）。

現在，例如， @Stateless在 CDi/Weld 中內部表示為@Dependent范圍而不是@RequestScoped因為 EJB 中的@Stateless bean 被重用，您無法真正了解它們的狀態。 在 CDI 中使用@RequestScoped時，您激活請求上下文（讓我們堅持使用 HTTP，因此通過發送某些內容來激活它），這會觸發所有@RequestScoped bean 的創建。 請求后所有這些 bean 都被銷毀，不再使用。 所以你可以完全依賴你放入的東西，你也可以確保它在請求后不會存活。

另一個故事是@ApplicationScoped與@Singleton 。 這些確實非常相似，最重要的細節可能是 CDI 創建自己的 bean 代理這一事實。 但這對於這個問題來說太詳細了，我認為您現在可以認為它們具有可比性。

@SessionScoped (CDI) 和 @Stateful (Java EE) 之間的區別

現在終於到了原來的問題。 我認為要大致掌握這些差異，您需要了解 CDI 在上下文中運行的事實。 它總是激活上下文（在這種情況下是會話上下文），並且此時一組@SessionScoped bean 出現，您可以與它們通信，它們具有值和狀態等。上下文相互交錯，因此同時請求上下文可能存在並且應用上下文確實存在。 所以我們可以說@SessionScoped與會話綁定並由容器控制，而@Stateful為您提供了一個用戶管理的會話，其生命周期由客戶端管理，並且在此基礎上還添加了許多其他功能。

有時您可以在一個 bean 上看到兩個注釋的原因是人們將它們結合起來以獲得兩全其美 - 容器管理的生命周期和添加的功能。 但請注意，雖然@Stateful使用不多（選擇加入@Stateless通常更有意義），但@SessionScope更加通用，幾乎適用於任何基於會話的場景。

希望它至少能說明一些問題，恐怕這是一個非常復雜的話題。

Answer 2

EJB Beans 默認給你事務，CDI Beans 不。

我認為這就是區別