web-dev-qa-db-ja.com

MVCデザインパターン、サービスレイヤーの目的？

次のレポパターンがあるとします。

interface IGenericRepo<T> where T : class
{
     IEnumerable<T> GetAll();
     T GetById(object id);
     void Insert(T obj);
     void Update(T obj);
     void Delete(T obj);
     void Save();
}

interface ICustRepo : IGenericRepo<Cust>
{
     IEnumerable<Cust> GetBadCust();
     IEnumerable<Cust> GetGoodCust();
}

public class CustRepo : ICustRepo<Cust>
{
     //implement method here
}

それから私のコントローラーで：

public class CustController
{
     private ICustRepo _custRepo;

     public CustController(ICustRepo custRepo)
     {
         _custRepo = custRepo;
     }

     public ActionResult Index()
     {
         var model = _custRepo.GetAll();
         return View(model);
     }

     public ActionResult BadCust()
     {
         var model = _custRepo.GetBadCust();
         return View(model); 
     }
}

基本的に私のパターンは次のようなものです

View <-> Controller -> Repo -> EF -> SQL Server

多くの人がこれをやっているのを見ました

View <-> Controller -> Service -> Repo -> EF -> SQL Server

だから私の質問は：

  1. なぜ、いつ必要なのかservice layer？すべての非ジェネリックメソッドは既にICustRepoに実装されているので、それは単に別の不要なレイヤーを追加するだけではありませんか？

  2. サービスレイヤーはDTOまたはmy ViewModelを返す必要がありますか？

  3. サービスレイヤーは私のリポジトリと1：1でマッピングする必要がありますか？

私は数日間周りを見回しましたが、答えに満足していません。

どんな助けでも歓迎され、悪い英語をお詫びします。

ありがとうございました。

更新：

リポジトリとサービスレイヤーの違い？

私はこれをすでに読んだ。私はこれら2つの違いを知っていますが、理由と目的を知りたいです。だから私の質問には答えません

c#asp.net-mvcentity-frameworkdesign-patternsrepository
17
warheat1990

TL; DR

  1. 以下の説明を参照してください
  2. サービスレイヤーの上にあるレイヤーは、サービスレイヤーの下にさらにレイヤーが存在することを「認識」してはなりません。
  3. 必ずしもそうとは限りません。たとえば、1つのタイプのデータを2つのテーブルに分散させ、「コア」は1つだけを見ることができるため、データアクセスレイヤーは「グループ化」とサービスレイヤータイプを返します。

説明

典型的な3層アーキテクチャは、プレゼンテーション層、サービス/ドメイン層、データアクセス層（DAL）で構成されています。

サービス層は、アプリケーションの「コア」と考えてください。通常、サービスレイヤーには、DALに実装されるリポジトリインターフェイスのみがあります。

そのため、データへのアクセス方法を「簡単に」切り替えることができます。結局のところ、プレゼンテーション層はDALが存在することさえ「認識」していないため、サービス層によって返されるオブジェクトはDAOであってはなりません。

シナリオ：3層ソリューションがあります。現在、すべてのレイヤーを持つことはあまり意味がありません。

      /-------------------\
      |      Web App      | <--- Presentation Layer
      |-------------------|
      |  Service Library  | <--- Service Layer
      |-------------------|
      | Entity Framework  | <--- Data Access
      \-------------------/

REST API in ASP.NET MVC WebApi

      /--------------------\
      | Web App | REST API | <--- Presentation Layer
      |--------------------|
      |  Service Library   | <--- Service Layer
      |--------------------|
      |  Entity Framework  | <--- Data Access
      \--------------------/

たとえば、Entity Frameworkをデータアクセスとして使用する必要がなくなり、NHibernateを使用したいとします。

      /--------------------\
      | Web App | REST API | <--- Presentation Layer
      |--------------------|
      |  Service Library   | <--- Service Layer
      |--------------------|
      |     NHibernate     | <--- Data Access
      \--------------------/

新しい形式のプレゼンテーションを追加し、データへのアクセス方法を切り替えましたが、サービス層は変更されていないことに注意してください。

通常、サービス層はデータアクセス層に実装されるインターフェイスを公開するため、必要な「抽象化」を実現できます。

私は大学でこのアーキテクチャを使用してプロジェクトを実装しました。あなたはコードをチェックアウトすることができます [〜＃〜]ここ[〜＃〜]

これがお役に立てば幸いです。私が説明するのがとても退屈な場合は申し訳ありません@説明すること：P

22
Driver

Ad.1サービスレイヤーは、ビジネスロジック全体に配置する必要があります。それは、個別の責任についての詳細です。

  • コントローラ-viewModelを準備して特定のビューに渡す責任があります。

  • リポジトリ-DBからのエンティティの収集を担当する抽象レイヤー

  • サービス-複雑なロジックを担当します。サービスが多くのエンティティを使用してロジックを作成し、DTOのみを返す場合がよくあります。

Ad.2私の意見では、サービスレイヤーは、コントローラーのviewModelsにマップされるDTOオブジェクトを返す必要があります。

Ad.3いいえ、そうではありません。あなたの例では、GetBadCustとGetGoodCustをリポジトリからサービスに移動し、DTOを返すことができます

5
Piotr Czarnecki