DI Constructor Injection Neatness

Question

Okay, also ich bin auf der Suche nach bestimmten Tipps über Dependency Injection und wie man es benutzt.

Grundsätzlich habe ich eine MVC-Website, die Ninject (und das Ninject MVC-Paket) verwendet. Wenn ich also die MVC-Seite erstelle, verwende ich die Konstruktorinjektion in den Controllern. Das ist in Ordnung, aber IMO ein bisschen "hässlich", aber die Hauptsache, die ich nicht mag, ist es, alle injizierten Repositories in die anderen Klassen zu übergeben, es scheint nur ein bisschen OTT wie 6 Repositories-8 Repositories passieren zu müssen eine statische Methode oder ein Objektkonstruktor.

Nicht zu erwähnen, dass ich auf einigen meiner Seiten an fast jedem Repository arbeiten muss, damit der Controller-Constructor riesig und nicht überschaubar wird.

Gibt es noch andere Optionen, die meinen Code nicht so sehr durcheinander bringen? Ich möchte sie nicht wirklich als einzelne "Einstellungs" -Objekte weitergeben, da dies das Problem nur auf eine andere Codezeile verschiebt.

Ich verwende auch die gleichen Klassenbibliotheken für Konsolen/Desktop-Anwendungen. Ich mag die Idee, DependencyResolver.Current in den Klassenbibliotheken zu verwenden, aber jeder sagt, dies ist ein Anti-Pattern und Konstruktorinjektion sollte verwendet werden.

Haben Sie vielleicht eine MyProjectDIContext-Klasse, die ein Wörterbuch hat, das ich mit den injizierten Typen in den Controller-Konstruktoren auffüllen kann, und dann den Kontext an alle Methoden wie benötigt übergeben?

Ich habe nach dem Antwort-Bit gesucht Ich kann nicht ganz scheinen, etwas zu finden, das gut passt.

Answer 1

Okay, ich habe anscheinend einen Weg gefunden, dies zu tun, der nicht so stinkt!

Ich dachte, wenn Sie zum Beispiel MVC verwenden, würden Sie die Repositories über den Konstruktor einholen und das war die einzige Möglichkeit, die Abhängigkeiten aufzulösen.

Nach einigen Arbeiten, um Abschnitte von wiederverwendbarem Code in IoC-freundliche Interfaces und deren Implementierungen zu verschieben, bemerkte ich, dass beim Erstellen Referenz IMyInterface in einem Controller-Konstruktor der Standardkonstruktor der implementierenden Klasse ausgeführt wird und Sie andere IoC-Klassen ziehen können als aufgelöste Repositories von dort.

Das mag allgemein bekannt sein, aber es macht die Dinge viel besser und löst das Problem, das ich hatte.

---

Beispiel

Regler

public IDefaultTemplateManager DefaultTemplateManager { get; set; } 

public DefaultController(IDefaultTemplateManager defaultTemplateManager) { 
    this.DefaultTemplateManager = defaultTemplateManager; 
} 

public ActionResult MyAction(FormCollection collection) { 
    DefaultTemplateManager.Process("MyKeyHere"); 
    View(); 
} 

IDefaultTemplateManager

public interface IDefaultTemplateManager { 
    ProcessResponse Process(string UniqueKey, DefaultTemplateManagerEditMode DatabaseName, string DefaultTemplateName); 
} 

DefaultTemplateManager

public class DefaultTemplateManager : IDefaultTemplateManager { 

     protected IRepository<MyEntity1> MyEntityRepo1 { get; set; } 
     protected IRepository<MyEntity2> MyEntityRepo2 { get; set; } 
     protected IRepository<MyEntity3> MyEntityRepo3 { get; set; } 
     protected IRepository<MyEntity4> MyEntityRepo4 { get; set; } 
     protected IRepository<MyEntity5> MyEntityRepo5 { get; set; } 
     protected IRepository<MyEntity6> MyEntityRepo6 { get; set; } 

     public DefaultTemplateManager(IRepository<MyEntity1> MyEntityRepository1, IRepository<MyEntity2> MyEntityRepository2, IRepository<MyEntity3> MyEntityRepository3, IRepository<MyEntity4> MyEntityRepository4, IRepository<MyEntity5> MyEntityRepository5, IRepository<MyEntity6> MyEntityRepository6,) { 
      this.MyEntityRepo1 = MyEntityRepository1; 
      this.MyEntityRepo2 = MyEntityRepository2; 
      this.MyEntityRepo3 = MyEntityRepository3; 
      this.MyEntityRepo4 = MyEntityRepository4; 
      this.MyEntityRepo5 = MyEntityRepository5; 
      this.MyEntityRepo6 = MyEntityRepository6; 
     } 

     public ProcessResponse Process(string UniqueKey) { 
      /* Do Work */ 
     } 

Answer 2

Eines der großen Vorteile von Constructor Injection ist, dass es Probleme bei der Konstruktion und Wartung deutlich macht. Wenn Sie die Konstruktorinjektion verwenden, wird es sehr einfach, die Anzahl der Abhängigkeiten einer Klasse zu sehen, während ohne Konstruktorinjektion eine Klasse immer noch die gleiche Anzahl von Abhängigkeiten hat, aber sie sind versteckt.

Das Problem, das Sie sehen, heißt Constructor Over-injection und es ist ein Design-Geruch, weil es anzeigt, dass Sie die Single Responsibility Principle (SRP) verletzen. Die SRP-Guides halten Ihre Klassen klein, fokussiert und vor allem: wartbar.

Gibt es noch andere Optionen, die meinen Code nicht so sehr durcheinander bringen?

Absolut: machen Sie kleinere Klassen. MVC-Controller werden in der Regel sehr groß, wenn wir Methoden eines bestimmten Konzepts wie "Kunde" oder "Bestellung" gruppieren. Dies bedeutet jedoch, dass ein Controller eine ständig wachsende Klasse ist, die für jedes neue Feature, das ankommt, geändert werden muss. Dies ist eine Verletzung der Open/closed Principle, die besagt, dass wir uns bemühen sollten, ein System zu haben, in dem wir neue Funktionen hinzufügen können, ohne bestehende Klassen zu berühren.

Die Lösung besteht daher nicht darin, zu Service Locator anti-pattern oder Property Injection zurückzukehren, sondern kleinere Klassen zu erstellen, die eine bestimmte Sache ausführen. Constructor Injection sollte Ihre primäre Methode zur Anwendung von Dependency Injection sein, auch in Klassenbibliotheken.

Answer 3

Es scheint, dass Ihr Controller Repositorys zu anderen Klassen mischt. stattdessen lassen Ninject Sie diese Klassen liefern:

public class Controller 
{ 
    public Controller(IDependencyFactory dependency) { } 
} 

public interface IDependencyFactory 
{ 
    IDependency CreateDependency(); 
} 

public interface IDependency 
{ 
} 

public class Dependency : IDependency 
{ 
    public Dependency() { } 
} 

public class Program 
{ 
    public static void Main() 
    { 
     var standardKernel = new StandardKernel(); 
     standardKernel.Bind<IDependencyFactory>().ToFactory(); 
     standardKernel.Bind<IDependency>().To<Dependency>(); 
    } 
} 

Sie keine Implementierung von IDependencyFactory schreiben müssen, dass durch die Werkserweiterung behandelt. Ihre Dependency -klasse erhält ihre Abhängigkeiten von Ninject.