1

Ich habe 3 ProjektdateienWo kann ich meinen Ioc (Ninject) -Code in mein Service-Layer-Projekt einfügen?

webui - controllers and views 
framework - service layer and repos 
tests- unit tests 

So wie ich es sehe, ist, dass meine Controller nur auf meine Dienstschicht (enthält meine Business-Logik) sprechen. Die Service-Schicht wird mit den Repos sprechen und Datenbankdaten abrufen.

Mein Repo wird nur die Datenbank tun und Daten zurückgeben.

Jetzt, wenn ich Einheit testen möchte, muss ich gefälschte Service-Schichten und gefälschte Repositories haben.

So kann ich die Controller isoliert und die Service-Schichten isoliert testen.

Wo also lege ich meinen Ninject-Code in meine Framework-Klassenbibliothek, damit ich ihn mit meiner Service-Ebene verwenden kann?

bearbeiten

Steven sagen Sie, ich sollte so etwas wie dieses

// Setup ninject in globalen aspx mit mvc Erweiterung tun

// jetzt binden das Zeug

private class SportsStoreServices : NinjectModule 
     { 
      public override void Load() 
      { 

       Bind<IAdminService>().To<AdminService>(); 
       Bind<IAdminRepo>().To<AdminRepo>(); 
      } 
     } 

// Controller

public class AccountController : Controller 
    { 
     // 
     // GET: /Account/ 

    private IAdminService adminService; 

public AccountController(IAdminService adminService) 
     { 
    this.adminService = adminService; 
} 


     public ActionResult Login() 
     { 
      var getAllAdmins = adminService.GetAllAdmins(); 
      return View(); 
     } 

    } 

// Service Layer

public class AdminService : IAdminService 
{ 

    private IAdminRepo adminRepo; 
    public AdminService(IAdminRepo adminRepo) 
    { 
     this.adminRepo = adminRepo; 
    } 

    public List<Admins> GetAllAdmins() 
    { 

     return adminRepo.GetAllAdmins(); 
    } 

} 


//Repo 
    public class AdminRepo : IAdminRepo 
    { 
     public List<Admins> GetAllAdmins() 
     { 
      // some query to get all admins 
     } 
    } 
+0

Verwenden Sie ninject.web.mvc? https://github.com/ninject/ninject.web.mvc – dotjoe

+0

Die Service-Schicht weiß nichts über Ninject. – dotjoe

+0

Derzeit nicht. Ich folgte nur, was der Autor in pro asp.net mvc 2.0 tat. Aber das würde nicht nur mein Problem mit Webui Teil lösen. Nicht die Service-Schicht? (Was ist in seinem eigenen Projektordner zusammen mit den Repo-Klassen) – chobo2

Antwort

5

Wenn folgen Sie den Injection Abhängigkeitsmuster korrekt (und vollständig) der einzige Ort, den Sie benötigen, um Ihre IoC-Container ist in der Anwendung root (in Ihrem Fall Ihr Webprojekt referenzieren). Für MVC haben Sie normalerweise eine ControllerFactory, die weiß, wie Sie neue Controller mit Ihrem bestimmten IoC-Framework erstellen. Ihre Controller werden um die Konstruktorinjektion herum entworfen, sodass Ihr IoC-Framework automatisch alle Abhängigkeiten injizieren kann. In der Regel wird die Konstruktorinjektion während des gesamten Projekts verwendet. Auf diese Weise können Sie den Rest Ihres Codes die gewählte IoC-Implementierung ignorieren lassen.

Bei Komponententests würden Sie normalerweise die Konstruktorinjektion verwenden, um die Abhängigkeiten manuell zu injizieren. Dies erspart Ihnen die Konfiguration Ihres IoC-Frameworks für Ihre Komponententests. Die Verwendung einer IoC-Bibliothek in Ihrem Testprojekt ist schmerzhaft, da Sie oft möchten, dass verschiedene Abhängigkeiten pro Testfall zurückgegeben werden, und Test-Frameworks führen Ihre Tests häufig parallel durch. Am besten ist es, nicht verwenden Sie ein IoC-Framework in Ihren Tests, aber rufen Sie den Konstruktor eines Typs im Test selbst.

Der Trick bei Komponententests mit DI besteht darin, dass Ihre Komponententests wartbar bleiben. Dies können Sie beispielsweise tun, indem Sie die Erstellung eines Testtyps in eine Factory-Methode extrahieren. Dadurch können Sie einen solchen Konstruktor an einer Stelle in Ihrem Code aufrufen. Wenn sich der Konstruktor ändert, müssten Sie Ihren Testcode an einer Stelle ändern. Ich habe viel über das Schreiben wartbarer Komponententests durch das Buch The Art of Unit Testing gelernt. Ich kann es empfehlen.

1

Bei Projekt sollte die DI an der Stelle sein, an der die Objektkomposition passieren kann. Zum Beispiel im WCF-Service-Projekt können wir es tun, mit IInstanceProvider, IN asp.net Global.asax. Grundregel: Stellen Sie sicher, dass der DI der Startpunkt der Anwendung ist