Die Verwendung von Dependency Injection-Frameworks für Klassen mit vielen Abhängigkeiten

Question

Ich habe verschiedene Dependency Injection-Frameworks für .NET angeschaut, da ich denke, dass das Projekt, an dem ich arbeite, davon sehr profitieren würde. Auch wenn ich denke, dass ich ein gutes Verständnis von den Fähigkeiten dieser Frameworks habe, bin ich mir immer noch nicht ganz im Klaren darüber, wie man sie am besten in ein großes System integriert. Die meisten Demos (verständlicherweise) beziehen sich auf ziemlich einfache Klassen, die ein oder zwei Abhängigkeiten haben.

Ich habe drei Fragen...

Erstens, wie gehst du mit diesen üblichen, aber uninteressanten Abhängigkeiten um, z.B. ILog, IApplicationSettings, IPermissions, IAudit. Es scheint übertrieben zu sein, dass jede Klasse diese als Parameter in ihrem Konstruktor hat. Wäre es besser, eine statische Instanz des DI-Containers zu verwenden, um sie abzurufen, wenn sie benötigt werden?

MyClass(ILog log, IAudit audit, IPermissions permissions, IApplicationSettings settings)
// ... versus ...
ILog log = DIContainer.Get();

Zweitens, wie gehst du mit Abhängigkeiten um, die eventuell verwendet werden könnten, aber teuer in der Erstellung sind. Zum Beispiel - eine Klasse könnte von einem ICDBurner-Interface abhängig sein, möchte aber nicht, dass die konkrete Implementierung erstellt wird, es sei denn, die CD-Brennfunktion tatsächlich verwendet wird. Gibst du Interfaces an Factories weiter (z.B. ICDBurnerFactory) im Konstruktor, oder greifst du auch hier auf eine statische Methode zurück, um direkt auf den DI-Container zuzugreifen und ihn dann abzurufen, wenn er benötigt wird?

Drittens, angenommen, du hast eine umfangreiche Windows Forms-Anwendung, in der das GUI-Top-Level-Komponente (z.B. MainForm) das übergeordnete Element von potenziell Hunderten von Unterpanelen oder Modalformularen ist, von denen jedes mehrere Abhängigkeiten haben kann. Bedeutet dies, dass MainForm so eingerichtet sein sollte, dass es alle Abhängigkeiten seiner Kinder enthält? Und wenn ja, würde das nicht dazu führen, dass sich ein riesiges, selbst aufblasendes Monster bildet, das jede einzelne Klasse konstruiert, die es jemals brauchen könnte, sobald du MainForm erstellst, und dabei Zeit und Speicher verschwendet?

Answer 1

Um meine erste Frage teilweise zu beantworten, habe ich gerade einen Blog-Beitrag von Jeremy Miller gefunden, der zeigt, wie Structure Map und Setter-Injection verwendet werden können, um öffentliche Eigenschaften Ihrer Objekte automatisch zu befüllen. Er verwendet ILogger als Beispiel:

var container = new Container(r =>
{
    r.FillAllPropertiesOfType().TheDefault.Is
        .ConstructedBy(context => new Logger(context.ParentType));
});

Dies bedeutet, dass alle Klassen mit einer ILogger-Eigenschaft, z.B.:

public class KlasseMitLogger
{
    public ILogger Logger { get; set; }
}

public class KlasseMitLogger2
{
    public ILogger Logger { get; set; }
}

werden ihre Logger-Eigenschaft automatisch eingerichtet haben, wenn sie erstellt werden:

container.GetInstance();