私が理解していることから、MVC は、コントローラーである「接着剤」を介して、クラス定義 (モデル) をプレゼンテーション (ビュー) から分離します。コントローラーは単一の責任を持つ必要があるため、テスト可能です。ViewModel は、複数のエンティティからのデータをまとめて、ビューのコントローラーからのデータを「処理」するために使用されます。
ビジネス ロジックにはあまり場所がないように思われるので、サービス用の別のレイヤーが適していると考えています。このレイヤーをどこに配置するか、またはサービスを構築する方法がわかりません。一連の機能を含む「サービス」と呼ばれるクラスにする必要がありますか? 私は MVC に少し慣れていないので、読み物、サンプル、または一般的な初心者向けのヒントは素晴らしいものです。
私は通常、ASP.NET MVC アプリケーションを開発するときにサービス レイヤーを使用します。これは、Martin Fowler がPatterns of Enterprise Application Architecture で説明しているService Layer Patternに似ています。ビジネスロジックをカプセル化し、コントローラーをかなり薄くします。基本的に、コントローラーはサービス層を使用してドメイン モデルを取得し、それをビュー モデルに変換します。また、ユニット オブ ワーク デザイン パターンを使用してトランザクションを処理し、リポジトリ デザイン パターンを使用してデータ アクセス レイヤーをカプセル化し、ユニット テストを容易にし、ORM を簡単に交換できるようにします。この図は、私が MVC アプリケーションで使用する典型的なレイヤーを示しています。
この図では、サービス層は「アプリケーションまたはドメイン層」とラベル付けされています。これは、「サービス層」という用語を使用すると混乱する人がいるからです。彼らは、これが Web サービスであると考える傾向があります。実際には、ASP.NET Web API や WCF などのお気に入りの Web サービス テクノロジやコントローラーで使用できるアセンブリです。
命名規則に関しては、通常、ドメインとそれに続くサービスを記述するものを使用します。たとえば、ユーザー メンバーシップを処理するサービス レイヤーがある場合、MembershipService というクラスを作成します。このクラスには、メンバーシップ ドメインを照会および操作するためにコントローラーと Web サービスが必要とするすべてのメソッドが含まれます。複数のサービス層を持つことができるように、同じアプリケーションに複数のドメインがある場合があることに注意してください。ここで言いたいのは、アプリケーション全体を処理する 1 つのモノリシック サービスを用意する必要はないということです。
私のアドバイスは、「サービス」と呼ばれる別のクラスを作成することです。それらを別のクラス ライブラリ (または名前空間) プロジェクトに配置し、MVC フレームワーク インフラストラクチャから独立させます。何らかの依存性注入も使用することをお勧めします (コンストラクター注入が最適です)。次に、サービス クラスは次のようになります。
public class MyService : IMyService
{
IFirstDependency _firstService;
ISecondDependency _secondService;
public MyService(IFirstDependency firstService, ISecondDependency secondService)
{
}
public Result DoStuf(InputDTO)
{
// some important logic
}
}
次に、コントローラーからこれらのサービスを使用します。完全な例については、こちらをご覧ください。
リポジトリによると、最新の ORM (NHibernate、EntityFramework) を使用する場合は、それらを使用しないことをお勧めします。これは、ビジネス ロジックがサービス レイヤーにカプセル化され、データベースが ORM フレームワークで既にカプセル化されているためです。
「ビジネス ロジックはモデルではなくサービスにある」からの引用ですか? :
MVP/MVC/MVVM/MV* アーキテクチャでは、サービスはまったく存在しません。または、そうである場合、この用語は、コントローラーまたはビューモデルに注入できる汎用オブジェクトを指すために使用されます。ビジネス ロジックはモデルにあります。複雑な操作を調整するために「サービス オブジェクト」を作成する場合、それは実装の詳細と見なされます。悲しいことに、多くの人がこのように MVC を実装していますが、モデル自体は何もせず、UI のプロパティの集まりにすぎないため、アンチパターン (Anemic Domain Model) と見なされています。
一部の人々は、100 行のコントローラー メソッドを採用し、それをすべてサービスに押し込むと、どういうわけかより優れたアーキテクチャになると誤解しています。実際にはそうではありません。おそらく不要な間接レイヤーをもう 1 つ追加するだけです。実際には、コントローラーはまだ作業を行っています。名前が不適切な「ヘルパー」オブジェクトを介して作業を行っているだけです。貧血ドメイン モデルを有用なモデルに変える方法の明確な例として、Jimmy Bogard のWicked Domain Modelsプレゼンテーションを強くお勧めします。これには、公開しているモデルと、ビジネス コンテキストで実際に有効な操作を慎重に検討することが含まれます。
MSDNのベストプラクティスの記事をご覧ください。
記事のアプリケーションのソースコードはここにあります。
リポジトリ パターンのようなものを求めているようですね。ここでそれについて読むことができます：
こちらの回答も役立つ場合があります。