0

私はJpaRepositoryを始めたばかりで、他の人がそれを処理するためにどのようなパターンを使用しているのか疑問に思っています。daoレイヤーに少なくとも2つのリポジトリを宣言することになったことに気付きました。

public interface CustomerRepository extends JpaRepository<Customer, Integer> {

Customer findById(Integer id); 
Page<Customer> findByLastname(String name, Pageable pageable);

Page<Customer> findByLastnameLike(String name, Pageable pageable);

}


 public interface FilmRepository extends JpaRepository<Film, Long>

Page<Film> findByTitleLike(String name, Pageable pageable);

Page<Film> findByDescriptionLike(String name, Pageable pageable);

Film findById(Long id);

}

ほとんどの人は、別々のコントローラーとサービスレイヤー（インターフェイスごとに1つ）を推奨/試して使用しますか、それとも可能な限り組み合わせますか？この質問はアプリケーション固有のものであると認識していますが、JpaRepositoryインターフェースを使用する場合、この点に関する一般的なベストプラクティスはありますか？私はそれらを組み合わせることになり、率直に言ってそれは混乱しているように見え、私は書き直しを考えています。

4

1 に答える 1

1

私がビジネスレイヤーを書くとき、私は共通のビジネスロジックを持つアクションを持つ1つのサービスを書くことを好みます。そのサービスは、複数のDAO（リポジトリ）クラスを使用し、それらを組み合わせることができます。通常、ビジネスサービスロジックでは、さまざまなデータベーステーブルにアクセスするだけでなく、追加のサービス（外部Webサービスの呼び出し、MQとの通信、ロギングサービス、セキュリティサービスなど）を使用する必要があります。これらすべてから、単一のビジネスレイヤークラスでは、複数のリポジトリや他のサービスクラスを使用する必要があると結論付けることができます。

ビジネス層は、リポジトリにアクセスするためのインターフェイスであるだけでなく、リポジトリと対話しながらビジネスロジックを実行する必要があります。

乱雑に見えるコードがある場合は、リファクタリングを試みる必要がありますが、すべてのビジネスサービスとコントローラーを分離した場合に大きなメリットがあるとは思えません。

しかし、あなたが言ったように、すべてのアプローチは非常にアプリケーション固有です。ただし、一般に、CRUDアプリケーションを作成する場合は、リポジトリごとに1つのビジネスクラスが適切なアプローチですが、複雑なビジネスロジックがある場合は、それは不可能です。

たとえば、次のように定義できます 

@RestResource(path = "customer", rel="customer")
public interface CustomerRepository extends CrudRepository<Customer, Integer> {

Customer findById(Integer id);

Page<Customer> findByLastname(String name, Pageable pageable);

Page<Customer> findByLastnameLike(String name, Pageable pageable);

}

そして、spring-data-restを使用してビジネスレイヤーロジックを作成せずにクルードRESTサービスを取得します（注：これは単なる例です）。

同じことがコントローラーにも当てはまります。

于 2013-03-19T09:42:00.297 に答える