從Spring @Service Bean直接使用EntityManager有什麼缺點嗎？

有什麼缺點，直接使用實體管理器從Spring事務的bean，而不是@Repository豆從Spring @Service Bean直接使用EntityManager有什麼缺點嗎？

@Service 
public class SomeService { 
    @PersistenceContext EntityManager em; 

    @Transactional(....) 
    public void doSomething(....) 
    { 
     // use entity manager here 
    } 
}

與

@Repository 
public class SomeRepository { 
    @PersistenceContext EntityManager em; 

    public void doSomething(....) 
    { 
     // use entity manager here 
    } 
}

來源

2012-08-17 ams

這是一個永恆的辯論，但它歸結爲你想堅持的風格。在JEE6世界中，這個問題的措辭是：「我們要單獨的EJB來充當DAO，或者只是在我們的服務中使用EntityManager」）。我喜歡Adam Bien的「真實世界Java EE模式」中的拇指規則：如果您發現自己正在將服務委託給存儲庫，那麼可以節省一些複雜性，削減中間人，然後從服務中使用EntityManager。有人可能會爭辯說，EntityManager是一種存儲庫。

至於可能出現的疑問：

EM永遠不會拋出SQLException（或任何檢查異常），所以你可能不需要翻譯@Repository給你，
如果你想重用從別的地方的功能，只使用該服務，它是作爲存儲庫可注射，

風格是很重要的人誰從服務總是單獨的daos肯定有一個正確的觀點。但是，你不能真正稱呼風格是「正確的」還是「不正確的」，它更像是「我喜歡它」或「我不喜歡它」的範疇。

來源

2012-08-17 08:55:21 fdreger

順便提一句，'PersistenceExceptionTranslationPostProcessor'不僅可以轉換SQLException，還可以轉換PersistenceException。 – 2012-08-22 20:43:54

@ php-coder：是的，你是對的 - 當然這是一個很好的觀點。我明確提到檢查異常 - 除非在同一個項目中使用許多不同類型的持久性，否則Spring的DataAccessException和PersistenceException幾乎沒什麼區別。 – fdreger 2012-08-23 17:10:44

是有：

它更清楚地分離問題（它隱藏了從服務類中的數據庫訪問的實現）
如果您有其他需要與存儲庫類似功能的服務，可以重新使用它。
用@Repository或@Service註釋類明確定義應用程序中的角色。如果你想使用方面，這是很方便的。
在春季，如果您的班級注有@Repository，則有資格申請DataAccessException翻譯（將SQLException轉換爲DataAccessException）。

來源

2012-08-17 08:35:09

從Spring @Service Bean直接使用EntityManager有什麼缺點嗎？

回答

相關問題