ASP.NET MVC-Projekt EF-Repository-Muster

Question

Wenn ich das Repository-Muster in einer ASP.NET MVC-Anwendung verwende Ich brauche DI, um das Programm wissen zu lassen, die Schnittstelle muss die Klassen zugeordnet werden. Wenn ich Unity implementiere, muss ich das DAL-Projekt zu meinem MVC-Projekt hinzufügen und dann die Typen in global.asax registrieren.

In meinen Augen ist es schlecht, dem MVC-Projekt den Namensraum der DAL-Schicht hinzuzufügen, da ist auch eine Business-Schicht dazwischen. Ich denke, es wäre schön, die DAL-Klassen in die Business-Schicht und nur die Business-Layer-Mappings in die MVC-App zu injizieren.

Wie geht es hier? Hast du Vorschläge?

UPDATE: Um es mir klar zu machen. In der Service-Schicht gibt es nur DTOs und die DI für die Geschäfts- und Datenzugriffsebene. In der Serviceschicht ordne ich die DTOs dem Domänenmodell zu. Was ich nicht verstehe ist, wie kann ich dann die Business-Layer-Methoden aufrufen?

Answer 1

Auch wenn Sie keine separate Serviceebene verwenden, können Sie erreichen, was Sie wollen, nämlich die MVC-Anwendung vom DAL-Projekt mit DI zu entkoppeln.

Die Methode besteht darin, ein paar Projekte/Assemblies hinzuzufügen, die Ihren IoC-Container mit bestimmten Instanzen der von Ihnen definierten Schnittstellen verbinden.

ich verwenden in der Regel diese Namenskonvention:

• MyCompany.MyProject.Infrastructure

• MyCompany.MyProject.Abstract

Ihr Haupt MVC-Projekt würde dann einen Verweis auf Ihre Abstract- und Infrastrukturprojekte. Ihr Infrastrukturprojekt würde einen Bezug zu den abstrakten und instanzspezifischen Projekten wie den Business- und DAL-Projekten haben. Innerhalb von Infrastructure projizieren Sie die Abhängigkeiten.

Sie müssen einen Mechanismus für Ihr MVC-Projekt einrichten, um Ihren IoC in der Infrastructure-Assembly zu booten. Sie können dies in Ihrer global.asax- oder als App_Start-Methode ausführen und eine Registration-Klasse in Ihrer Infrastructure-Assembly aufrufen.

Wir verwenden StructureMap, aber das Konzept ist das gleiche. Hier ist ein Beispielcode.

Erstellen Sie in Ihrer MVC-App eine App_Start-Methode zum Einrichten des 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); 
    } 
} 

In Ihrer Infrastructure Assembly verbinden Sie die Abhängigkeiten.

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; 
    } 
} 

Answer 2

Wenn Sie pragmatisch arbeiten möchten, erfordert eine echte 3-Tier-Architektur eine Service-Schicht. Zwischen dem Dienst und MVC sind Datenübertragungsobjekte (DTOs). Die Serviceebene verbirgt sowohl die DAL- als auch die Business-Schicht.

Wenn Sie es so einrichten, weiß der MVC selbst nichts über DAL, nur DTOs und Service (Verträge).

Answer 3

Sie sollten DI verwenden, um die Domänen-/DAL-Schnittstellen in Ihre Konstruktoren einzufügen. Dies hat eine Menge Vorteile, einschließlich der Möglichkeit, Ihre Schnittstellen beim Schreiben Ihrer Komponententests anzupassen. Sie können Autofac verwenden, um die Injektion zu verarbeiten.