2013-04-02 19 views
6

ASP.NET MVCアプリケーションでリポジトリパターンを使用する場合は、プログラムを知らせるためにDIが必要です。インターフェイスにクラスをマップする必要があります。 Unityを実装する場合は、DALプロジェクトをMVCプロジェクトに追加し、global.asaxに型を登録する必要があります。ASP.NET MVCプロジェクトEFリポジトリパターン

私の考えでは、DALレイヤーの名前空間をMVCプロジェクトに追加するのは悪いと思います。その間にもビジネスレイヤーがあります。私は、DALクラスをビジネスレイヤに、そしてビジネスレイヤマッピングだけをMVCアプリケーションに挿入するのは美しいと思います。

ここに行く方法は何ですか?提案はありますか?

更新日: わかりやすくするにはサービス層には、ビジネスとデータアクセス層のDTOとDIだけがあります。サービス層では、DTOをドメインモデルにマップします。私が理解していないことは、ビジネス層のメソッドをどのように呼び出すことができるかということです。

+0

レポを使用しても、DIを使用する必要はありません.2つの異なる問題を解決します。 –

+2

私は "タマネギの建築"を読んでみることをお勧めします、私はそれがプロジェクトの参考に良いアプローチだと思います。あなたのUIとDataAccessのレイヤーはどちらも外部にあるので、お互いを参照する上で問題はありません。 – Charlino

答えて

3

個別のサービスレイヤーを使用しない場合でも、DIを使用してMVCアプリケーションとDALプロジェクトを切り離すことができます。

これを行う方法は、IoCコンテナの上に定義したインタフェースの特定のインスタンスを結ぶ2つのプロジェクト/アセンブリを追加することです。

私は通常、この命名規則を使用します。

  • MyCompany.MyProject.Infrastructure

  • MyCompany.MyProject.Abstract

あなたの主なMVCプロジェクトは、その後への参照を持っているでしょう抽象プロジェクトとインフラストラクチャプロジェクト。インフラストラクチャプロジェクトには、ビジネスプロジェクトやDALプロジェクトのような抽象的なインスタンス固有のプロジェクトへの参照があります。インフラストラクチャプロジェクトでは、依存関係を配線します。

インフラストラクチャアセンブリでIoCをブートストラップするためにMVCプロジェクト用のメカニズムをセットアップする必要があります。 global.asaxまたはApp_Startメソッドで行い、Infrastructureアセンブリ内のRegistrationクラスを呼び出すことができます。

StructureMapを使用しますが、概念は同じです。ここにいくつかのサンプルコードがあります。

MVCアプリケーションでは、App_Startメソッドを作成してDIを設定します。

public static class StructuremapMvc 
{ 
    public static void Start() 
    { 

     // Create new Structuremap Controller factory so Structure map can resolve the parameter dependencies. 
     ControllerBuilder.Current.SetControllerFactory(new StructuremapControllerFactory()); 

     IContainer container = IoC.Initialize(); 

     DependencyResolver.SetResolver(new StructureMapDependencyResolver(container)); 

     GlobalConfiguration.Configuration.DependencyResolver = new StructureMapDependencyResolver(container); 
    } 
} 

インフラストラクチャアセンブリで、依存関係を配線します。

public static class IoC 
{ 
    public static IContainer Initialize() 
    { 
     ObjectFactory.Initialize(x => 
        { 
         x.Scan(scan => 
           { 
            scan.TheCallingAssembly(); 
            scan.WithDefaultConventions(); 
           }); 
         x.For<IRepositoryNum1>().Use<Num1Repository>(); 
         x.For<IRepositoryNum2>().Use<Num2Repository>(); 
         x.For<IRepositoryNum3>().Use<Num3Repository>(); 
        }); 

     return ObjectFactory.Container; 
    } 
} 
+0

このインフラストラクチャは、Alwynによって記述されたサービスレイヤーのようなものですが、DTOはありません。このアプローチは私にとって非常に良く見える、私はそれをテストします。 – Dominik2000

+0

はい、このアプローチは、サービス層と関連するDTOの有無にかかわらず使用できます。 – dblood

4

真実になりたい場合は、真の3層アーキテクチャではサービス層が必要です。サービスとMVCの間には、データ転送オブジェクト(DTO)があります。サービス層は、DALとビジネス層の両方を隠します。

このように設定した場合、MVC自体はDAL、DTO、サービス(契約)については何も知りません。

+0

これは私のアプローチです –

+0

OK、私は両方の方法をテストします。私は私に合ったものを見ます。 – Dominik2000

0

Domain/DALインターフェイスをコンストラクタに挿入するには、DIを使用する必要があります。これには、単体テストの記述時にインタフェースをmoqできるようにすることを含め、多くのメリットがあります。 Autofacを使用して注入を処理できます。

関連する問題