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