EFでASP.Net MVCアプリケーションを設計するにはどうすればよいですか？

Question

Entity Frameworkを使用してMVCアプリケーションをn層アプリケーションに構築する方法を概念化するのに少し問題があります。

通常、教科書3段になったアプリは、プレゼンテーションは、データアクセスについて何も知らないはず

データAccess->ビジネスいるロジック>プレゼンテーション

ようになるはずです。 EFでは、すべての層がモデルについて知る必要があります。だから、私のアーキテクチャは今のところもっと見える

Data Access->Business Logic 
    |    | 
     --------------- 
      | 
      MVC 

私はここに何かがないか、間違った方法で考えていますか？

データアクセス層としてEF自体を考えて、エンティティをビジネスロジックに入れるべきでしょうか？

Answer 1

あなたの質問は、MVCアプリケーションで "レイヤー"をどのように設計するかということです。 この単純なアーキテクチャを見て、私はMVCアプリケーション用に使っています。それはきれいで効率的なようです。

1. ソリューションのプロジェクト - ビジネスモデル - ビジネスドメインを表すPOCOクラスでいっぱいのシンプルなクラスライブラリ。ここではデータアノテーション、検証ロジックにはメタデータクラスを使用できます。

2. プロジェクト - EFベースのリポジトリ - 別の簡単なクラスライブラリ。ここで定義されているコンテキスト（EFコードは最初ですが、最初にEFデータベースを使用するか、最初にモデルを使うことができます - ビジネスモデルクラスライブラリにPOCO T4テンプレートを追加するだけです）、クラスセット - リポジトリ

3. プロジェクト - 私は通常、 "ServiceLayer"と呼ばれます（私は良い名前のために提案しています:) - リポジトリと他のサービス（別のプロジェクトで実装されている） ）ベースのアプリケーションの使用。 2.projectのリポジトリはこれらのインターフェイスを実装します

4. プロジェクト - MVC Webサイト。それは、リポジトリ（と他のサービス）のマッピングにDependency Injection（DependencyResolverでビルドし、Ninjectコンテナを使うことが大好きです）を使用します。

   スキニーコントローラ：

    
   public class SomethingController : BaseController 
   { 
       public ActionResult DoSomething(SomeBusinessThing input) 
       { 
        if (ModelState.IsValid) 
        { 
         var result = CustomerRepository.DoSomeBusinessLogicAndPersistenceAndStuff(input); 
         return View(result); // you can use AutoMapper here, if you dont want to use business object as viewmodels 
        } 
       } 
   } 
   

   マイリポジトリ「プロパティその後、あなたはそれは次のようになりますコンストラクタコントローラへの注入、またはいくつかの「怠惰」なアプローチ（下記参照）

を使用することができます"は私のBaseControllerから継承されています：

この「怠惰な」DIは、コントローラは多くのサービスを使用しますが、アクションごとに1〜2つしかないため、コンストラクタですべてを注入するのは非効率です。誰かがこのように依存関係を「隠している」と言えるかもしれませんが、このすべてを1つの場所、つまりBaseControllerに保存しておけばそれは大したことではありません。

まあ、リポジトリの実装は本当にあなたのビジネスです。 MVCアプリケーションでもいけないあなたがEFを使用している知っている、それはサービスのインタフェースのみを知っていると実装アンダーレイに気をdoesntの

Conslusion（あなたがする必要が後であればいつでも切り替えることができます！）：

• コントローラはスキニーです - ビジネスロジックはありません

• モデルはFATです - この場合、リポジトリはすべてのビジネスロジックをカプセル化します（もちろん、他のタイプのサービスも使用できます。 、MVC does not care、onlを知っている（I Yインタフェース）

• のviewmodelsは、ビューの入力されている（とViewModelには、直接あなたのビジネスモデルであるか、またはあなたが

Answer 2

EFエンティティはデータオブジェクトと考えることができ、別のビューモデルがビューに渡されます。 EFオブジェクトのデータを使用して、ビューモデル（ここではAutoMapperなどのライブラリが便利です）にデータを設定できます。このようにして、ビューはEFオブジェクトに直接依存することはなく、ビューモデルでのみ依存します。

Answer 3

は、私はあなたが本当に良いお勧めすることができ、「純粋」のviewmodels）を作成するためのAutoMapperを使用することができますドメインベースのアーキテクチャ設計に関する本を.NETプラットフォームでご紹介します。 Book siは.NET 4.0でN層ドメイン駆動アーキテクチャGUIDと呼ばれています。本では、EFとMVC（そしてSilverlight、IoC with Unityなどの他の多くのもの）を使って良いアーキテクチャを作成する方法を説明します。

ブックがこのアドレスでダウンロードすることができます。

http://msdn.microsoft.com/es-es/architecture/en/

また、サンプルアプリケーションは、非常に興味深いです：独立したPOCOクラスを作成する方法EFのためのエンティティを作成する

http://microsoftnlayerapp.codeplex.com/

ベストな方法永続層上にある。これらのドメインエンティティは、ドメイン（ビジネス）ロジックレイヤに含まれます。

本書では、プレゼンテーション、アプリケーション、ドメイン、インフラストラクチャ（ほとんどのデータ永続性）、クロスカッティングと分散サービスレイヤについて説明します。