EJB3 vs數據訪問對象

Question

我正在研究一個項目，我們需要決定如何公開我們的持久層。

目前在桌上有兩種選擇：

1）使用普通的DAO。這些將實現一個接口並在作爲EJB的業務組件中注入（可能使用Weld）。在內部他們會使用JPA/Hibernate進行持久化。

2）而不是使用注入的焊縫的DAO，它們將被實現爲的EJB，並與在業務組件@EJB注入。

是否真的有意義使用EJB的持久化層的時候，我們不使用它的功能（例如事務管理 - 業務層，涉及這一點）？

在使用EJB over Weld（或其他方式）時是否存在性能損失？

你認爲最好的選擇是什麼？

Answer 1

將EJB用於基於JPA的DAO非常自然。

如果交易通常在業務層（這也是EJB的你提到）交易自然會傳播給他們啓動。如果您想單獨使用DAO，那麼您的交易將開始。您現在可能不會使用此功能，但如果您需要它，它將完全免費。

此外，你應該永遠需要在自己的事務單一的操作，那麼當你的DAO是基於EJB，這是微不足道的。與DAO的EJB

注入業務的EJB可能有潛在的性能優勢。由於只有存根被注入到代理池中，注入相對便宜。您可以爲業務EJB注入許多DAO，這些DAO對於每個調用都可能需要也可能不需要。我不是100％確定CDI具有完全相同的能力。它當然有範圍和對話，但不是真正的存根委託給一個池。

如果您曾經需要JPA的extended persistence context，那麼有狀態會話bean實際上就是爲此而創建的，否則無狀態會話bean將用於DAO。

也就是說，CDI是更現代的組件模型和目前的想法似乎是EJB最終將被改造爲一組CDI註解。現在開始建立一個CDI代碼庫和知識可能實際上是一個長期的戰略利益，因此是CDI的代名詞。

所以要更直接地回答您的問題：是的，使用EJB作爲持久層是有意義的，但EJB或CDI絕對是錯誤的選項。