リポジトリパターンとビジネスロジック

Question

データレイヤーからデータを取得するリポジトリ（ CustomerRepository ）があります。ほとんどのビジネスロジックは、リポジトリが受け入れるまたは返すエンティティクラス（ Customer ）にあります。

ただし、（すべての顧客に適用される）グローバルエンティティビジネスロジックをどこに配置しますか？

たとえば、すべての顧客を特定のユーザーに戻したくない場合があります。そのロジックをリポジトリに入れたくありません。

Answer 1

Robert Munteanuに同意します。

基本的に、モデルに固有ではないビジネスロジックを中間層にロールアップします。中間層は、ビジネス層/ビジネスオブジェクト/ビジネスロジック層/などですが、単にサービス層と呼ばれます。 Webサービスである必要はありません。特定のアプリケーション領域の機能を集約するという点で、サービスという用語を広く使用しています。

基本的に、リポジトリ参照を含むCustomerServiceクラスがあります。プレゼンテーション層はサービス層クラスを参照します。

.netを使用し、おそらくNerdDinnerで概説されているように、リポジトリとしてLINQ to SQLを使用している名前から推測できる追加の区別があります。

通常、リポジトリはIQueryableをサービスレイヤーに返し、サービスレイヤーが複数のクエリをチェーン化して異なる結果セットを構築できるようにします。次に、サービスはToListまたは別の同様のメソッドを使用して式を評価し、プレゼンテーション層に返します。

Answer 2

サービスの背後にラップします。

Answer 3

別のリポジトリ（BusinessRuleRepository）に配置し、CustomerRepositoryで使用します。

または

ビジネスロジックがユーザーに表示される結果のみを制限している場合、Facadeパターンをファクトリで使用することができます。この場合、CustomerRepositoryとLimitedCustomerRepository（CustomerRepositoryをカプセル化する場合があります）を処理するICustomerRepositoryと、ユーザーに適切なICustomerRepositoryを返すCustomerRepositoryFactoryがあります。

Answer 4

これらのタイプの機能をサービスレイヤーに分離するのが方法だと思います。

最近、履歴データを使用して多くのエンティティで複雑な予測を行うシステムを構築しました。各エンティティのリポジトリにすべてのデータアクセスビットを配置します。複雑な予測ロジックをサービスレイヤーに保持し、必要に応じてリポジトリオブジェクトを渡しました。

追加のボーナスは、Web APIレイヤーを作成するだけで、すべての予測ロジックを外部システムに公開する簡単な方法があったことです。