2

直接从 Spring Service bean 而不是 @Repository bean 使用实体管理器有什么缺点吗

@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 
   } 
}
4

2 回答 2

6

这是永恒的争论之一，但归结为您希望坚持的风格。在 JEE6 世界中，问题的表述是：“我们应该制作单独的 EJB 来充当 DAO，还是只在我们的服务中使用 EntityManager”）。我喜欢 Adam Bien 的“Real World Java EE Patterns”中的经验法则：如果您发现自己创建的服务只是委托给存储库，那么可以省去一些复杂性，减少中间人，只使用服务中的 EntityManager。有人可能会争辩说 EntityManager 是一种存储库。

至于可能的疑问：

  • EM 永远不会抛出 SQLException（或任何已检查的异常），因此您可能不需要 @Repository 为您提供的翻译，
  • 如果您想重用其他地方的功能，只需使用该服务，它与存储库一样可注入，

风格很重要，总是将 daos 与服务分开的人当然有道理。但是你不能真正称一种风格为“正确”或“不正确”，它更多的是在“我喜欢它”或“我不喜欢它”的范围内。

于 2012-08-17T08:55:21.080 回答
2

是的，有：

  • 它更清晰地分离了关注点（它从服务类中隐藏了数据库访问的实现）
  • 如果您有其他服务需要与存储库类似的功能，则可以重用它。
  • @Repository用或@Service明确定义应用程序中的角色注释类。如果您想使用方面，这很方便。
  • 在 Spring 中，如果您的类带有注释，@Repository则它有资格进行 DataAccessException 转换（转换SQLException为DataAccessException）。
于 2012-08-17T08:35:09.353 回答