私はデータレイヤーからデータを取得するリポジトリ（CustomerRepository）を持っています。ほとんどのビジネスロジックは、リポジトリが受け入れるか返すエンティティクラス（Customer）にあります。リポジトリパターンとビジネスロジック
ただし、グローバルエンティティのビジネスロジック（すべての顧客に適用される）はどこに置かれますか？
たとえば、すべての顧客を特定のユーザーに戻したくない場合があります。私はその論理をリポジトリに入れたくありません。
私はRobert Munteanuに同意します。
基本的に、モデルに固有でないビジネスロジックを中間層にロールアップします。中間層はビジネス層/ビジネスオブジェクト/ビジネスロジック層/ etcですが、サービス層と呼ばれています。 Webサービスである必要はなく、特定のアプリケーション領域の機能を集約するという点でサービスという用語を幅広く使用しています。
基本的には、リポジトリ参照を含むCustomerServiceクラスがあります。プレゼンテーションレイヤーはサービスレイヤークラスを参照します。
NerdDinnerで概説されているように、あなたの名前から.netを推測し、おそらくLINQ to SQLをリポジトリとして使用するという別の違いがあります。
通常、リポジトリはIQueryableをサービス層に返します。これにより、サービス層チェーンが複数のクエリをまとめて異なる結果セットを構築できます。次に、サービスはToListまたは別の同様のメソッドを使用して式を評価し、プレゼンテーションレイヤーに返します。
別のリポジトリ（BusinessRuleRepository）に入れ、CustomerRepositoryにそれを使用させます。
OR
ビジネスロジックはユーザーのみが、あなたは工場でFacadeパターンを使用することがあります見ることができる結果を制限している場合。この場合、CustomerRepositoryとLimitedCustomerRepository（CustomerRepositoryをカプセル化する可能性があります）を処理するICustomerRepositoryと、そのユーザーの適切なICustomerRepositoryを返すCustomerRepositoryFactoryがあります。
私はこれらのタイプの機能をサービスレイヤーに分けるのが最善の方法だと思います。
私は最近、履歴データを使用して多数のエンティティと複雑な予測を行うシステムを構築しました。すべてのデータアクセスビットを各エンティティのリポジトリに格納する。私は複雑な予測ロジックをサービスレイヤーに保持し、必要に応じてリポジトリオブジェクトを渡しました。
さらに、Web APIレイヤーを作成するだけで、すべての予測ロジックを外部システムに簡単に公開することができました。
MVC Storefront by Rob Coneryは私をリポジトリパターンに変えましたが、残念ながら彼は実際にその決定をビデオで説明することなくサービス層をリファクタリングしました。だから、おそらくそれが最善の方法ではないと心配しました。 –
私は同様の問題に直面していましたが、これは最高のアーキテクチャですか？私は、工場とのレイヤーの上にある契約とのインターフェースについて心配しなくて、それを機能させることに集中しました。私はあまりにも多くの人がソリューションをオーバーアーキテクトする方法であることが分かります。コードベースのこの瞬間を構築する目的は、層と階層の独自の強靭さと完全性への賛辞ですか？リポジトリにデータを保存し、ビジネスサービスの "ビジネスロジック"、ビューのUIを見ていればいいと思います。 – blu
に行くと、ソフトウェアがやろうとしていることを達成し、リファクタリングし、ソフトウェアの目標を達成します。 – blu