Question

直接从Spring Service bean而不是@Repository bean

使用实体管理器是否有任何缺点

@Service
public class SomeService {
   @PersistenceContext EntityManager em; 

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

VS。

@Repository
public class SomeRepository {
   @PersistenceContext EntityManager em; 

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

Answer 1

这是永恒的辩论之一，但它归结为你想要坚持的风格。在JEE6世界中，问题是：“我们应该将单独的EJB作为DAO，或者只是在我们的服务中使用EntityManager”）。我喜欢Adam Bien的“真实世界Java EE模式”的拇指规则：如果你发现自己制作的服务只是委托给repositiories，那么为自己节省一些复杂性，削减中间人并从你的服务中使用EntityManager。有人可能会说EntityManager是一种存储库。

至于可能的疑虑：

EM永远不会抛出SQLException（或任何已检查的异常），所以你可能不需要@Repository给你的翻译，
如果您想重新使用其他地方的功能，只需使用该服务，它就像存储库一样可注入，

风格很重要，总是将服务与服务分开的人肯定有一个有效的观点。但是你不能把风格称为“正确”或“不正确”，它更多地出现在“我喜欢它”或“我不喜欢它”的范围内。

Answer 2

是的，有：

它更清晰地区分关注点（它隐藏了从服务类实现数据库访问）
如果您有其他需要与存储库类似功能的服务，则可以重复使用。
使用@Repository或@Service注释类明确定义应用程序中的角色。如果你想使用方面，这很方便。
在Spring中，如果您的班级使用@Repository进行注释，则可以使用DataAccessException转换（将SQLException转换为DataAccessException）。

从Spring @Service Bean直接使用EntityManager有什么缺点吗？

2 个答案: