2011-12-14 155 views
3

我們在我們的應用程序中使用CDI(JSR 299)(JSF2/Seam3.0 /休眠3.5.6/3.1.1的GlassFish)CDI注入Hibernate的實體

雖然我們無法注入資源(助手的POJO )在我們的託管bean中使用@Inject,我們不能在我們的Hibernate Entity類中做同樣的事情。

我們有一個基本實體類(@MappedSuperclass),所有實體對象派生自。兩類CDI注射均失敗。

@MappedSuperclass 
public class BaseBusinessObject implements Serializable 
{  
    @Inject 
    private TestClass testClass; //FAILS 
} 


@Entity 
@NamedQueries({ @NamedQuery(name = "Account.findAll", query = "SELECT b FROM Account b") }) 
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
public class Account extends BaseBusinessObject 
{ 
    @Inject 
    private TestClass testClass; //FAILS 

} 

它似乎可能是CDI的限制。任何人都可以確認CDI是否適用於Hibernate實體。

任何輸入將不勝感激。

感謝&問候

回答

3

我真的不知道CDI,但我真的不認爲這是可能的。 事件如果我們可以,在很多情況下,它可能會導致一個非常糟糕的設計。

你是否希望CDI爲整個應用程序創建一個hibernate實體,並在其中注入助手/服務/任何東西? 或者你是否希望CDI在你使用「新實體()」創建的實體中注入東西?


編輯: 一般一個日期時間utils的不持有任何國家,也不需要任何CDI注入的東西,所以爲什麼不把所有的方法靜態像我們在Apache的百科全書DateUtils找到?

如果您的日期時間使用情況需要一個狀態,請將其設爲單例(但要注意併發問題)。

如果您的日期時間utils需要調用其他CDI bean(因此它不能是靜態的),那麼您寧願將它設爲單例,並在單例中注入其他CDI bean。

但這是一個壞主意。 這可能會導致擁有一個業務層來管理回調業務層或類似事件的實體,這些業務層存在一些循環依賴問題以及實體與業務層之間的緊密耦合。

+0

嗨塞巴斯蒂安時,你應該非常小心,謝謝您的答覆。我們使用多個Hibernate實體,但它們都從基礎實體類派生(基本屬性,如創建日期時間)。我們試圖在這個基類中注入日期時間實用工具類來獲取實體創建時間,並且此注入失敗。 – gkari 2011-12-15 14:43:21

2

系統地使用JPA實體作爲CDI bean是個不好的做法(但是如果你願意的話,這是可能的)。這主要是因爲CDI的「C」:Context。

所有的CDI實現都使用代理機制來處理在一個不同作用域的bean中注入給定作用域的bean。由於大多數JPA實現使用代理來處理某些機制(例如延遲加載),所以您將在您的課堂中完成一系列具有不同生命週期的代理:一團糟!

焊接文檔,因爲即使這個問題上減弱:Chapter 5. Scopes and Contexts

但是它可能是一個暴露的實體bean的CDI在某些情況下是有用的,但你會更喜歡使用一個生產者這樣做:

@Produces 
@Named 
@RequestScoped 
private MyEntity produceMyEntity() 
{ 
    return new MyEntity(); //or any JPA lookup you'll need 
} 

這種方式是最方便的,但混合管理實體和CDI

+0

嗨安託萬,謝謝你的迴應。 我們不是試圖用CDI生成一個實體。該實體使用new()運算符生成。但是,根據Sebastien的規定,我們所有實體都從基礎實體類派生(基本屬性,如創建日期時間)。我們試圖在這個基類中注入日期時間實用工具類來獲取實體創建時間,並且此注入點失敗。 如果您需要更多信息,請讓我知道。 – gkari 2011-12-15 14:52:30