2

@Repository Bean ではなく、Spring Service 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

これは永遠の議論の 1 つですが、最終的にはあなたが守りたいスタイルに行き着きます。JEE6 の世界では、「DAO として機能する個別の EJB を作成するか、サービス内で単に EntityManager を使用するか」という質問があります)。Adam Bien の「Real World Java EE Patterns」の経験則が好きです。リポジトリに委任するだけのサービスを作成している場合は、複雑さを軽減し、仲介者をカットして、サービスから EntityManager を使用するだけです。EntityManager は一種のリポジトリであると主張する人もいるかもしれません。

考えられる疑問について：

  • EM は SQLException (またはチェックされた例外) を決してスローしないため、@Repository が提供する変換はおそらく必要ありません。
  • 他の場所から機能を再利用したい場合は、サービスを使用してください。リポジトリと同じくらい注入可能です。

スタイルは重要であり、daos とサービスを常に区別する人々には、確かに正当な理由があります。しかし、スタイルを「正しい」または「正しくない」と実際に呼ぶことはできません。それは、「好き」または「嫌い」の領域にあります。

于 2012-08-17T08:55:21.080 に答える
2

はい、あります：

  • 懸念事項をより明確に分離します (データベース アクセスの実装をサービス クラスから隠します)。
  • リポジトリと同様の機能を必要とする他のサービスがある場合は、再利用できます。
  • @Repositoryまたはでクラスに注釈を付けると@Service、アプリケーションでの役割が明確に定義されます。これは、アスペクトを使用する場合に便利です。
  • Spring では、クラスにアノテーションが付けられている場合、DataAccessException 変換 (に@Repository変換) の対象となります。SQLExceptionDataAccessException
于 2012-08-17T08:35:09.353 に答える