Ich baue eine Repository-Basisklasse mit Entity Framework, wo alle Entitäten Repository erben wird. Ich möchte die DatabaseContext in der Basisklasse mit Dependency Injection mit Ninject injizieren. Ich denke, die Constructor Injection ist der richtige Weg, aber dies mit Constructor Injection in der abgeleiteten Klasse I zu tun, muss Parameter an Konstruktor in der Basisklasse übergeben und ich will es nicht. Daher ist eine Setter-Injektion besser geeignet?
Hier ist mein Code:
%Vor%Wenn ich im obigen Beispiel die Konstruktorinjektion verwende, muss in meiner abgeleiteten Klasse das DatenbankContext-Objekt an die Basisklasse übergeben. Dies möchte ich nicht für alle meine abgeleiteten Klassen tun :
%Vor%Setter Injection anstelle von Constructor Injection ist ein guter Weg, um das zu lösen? Was ist der beste Weg?
Aktualisierung:
Mit Setter Injection haben meine abgeleiteten Klassen keine Konstruktoren:
%Vor%Mein Kontext ist nur einer in allen Anwendungen. Ich brauche keine abgeleitete Klasse, um das Kontextobjekt zu übergeben, aber ich möchte es in die Basisklasse injizieren, um in Zukunft Mocks für Tests zu verwenden.
Ich löse das Problem:
Sorry, ich bin mit der Frage verwirrt, aber ich löse mein Problem beim Aufbau einer Factory:
%Vor%Und meine abgeleitete Klasse wird so aussehen:
%Vor%Und meine Fabrik so:
%Vor%Property Injection bedeutet, dass die Abhängigkeit optional ist, während Constructor Injection impliziert, dass die Abhängigkeit erforderlich ist. Wählen Sie ein Muster entsprechend.
In mehr als 95% der Fälle ist Constructor Injection das richtige Muster. Was ist damit nicht gefällt?
Ich glaube nicht, dass es einen "besten Weg" gibt.
Konstruktor- und Setter-Injektion sind nicht exakt gleichwertig, da Setter-Injektion Ihnen ein wenig mehr Flexibilität bietet. Hier ist, wie ich zwischen den beiden wählen:
Nehmen wir an, Sie erstellen ein Objekt A und A benötigt ein B-Objekt, um zu arbeiten. Die Frage, die gestellt werden muss, lautet: Ist es möglich, dass A existiert, ohne dass ein B damit verbunden ist? Ist es ein gültiger Zustand für das A-Objekt, kein B zu haben? Manchmal macht es keinen Sinn, dass A jemals eine Null B hat, dann ist die Konstruktorinjektion die bessere Lösung. Wenn es ok ist, dass B später A zugeordnet wird und nicht unbedingt zur Konstruktionszeit, dann gehe mit Setter-Injektion. All dies hängt von der Domäne ab, die Sie modellieren möchten, und die Antworten ändern sich von Situation zu Situation.
Wirklich, ich kann kein Problem mit der Übergabe eines Parameters an eine Basisklasse sehen. Aber wenn das eine absolute Voraussetzung ist, könntest du das immer tun:
Nun können Ihre abgeleiteten Klassen wie folgt aussehen:
%Vor%Jetzt können Sie Konstruktoren injizieren, ohne einen Parameter an den Basiskonstruktor zu übergeben. Aber es ist wirklich das Gleiche.
Ich mag die Idee der Setter-Injektion ehrlich nicht, weil es so aussieht, als wäre der DatabaseContext eine erforderliche Abhängigkeit. Führen Sie für erforderliche Abhängigkeiten die Konstruktorinjektion aus. Wenn es optional wäre, dann mach auf jeden Fall weiter und setze die Injektion.
BEARBEITEN:
Aufgrund unserer langen Konversation in den Kommentaren habe ich ein viel besseres Verständnis dafür, was Sie erreichen möchten.
Wenn Sie Ihre abgeleiteten Klassen vom DatabaseContext entkoppeln möchten, sollten Sie sie besser anders gestalten. Es ist schwierig, eine abgeleitete Klasse von den Abhängigkeiten ihrer Basisklasse zu entkoppeln, und wenn Sie denken, sie sollten entkoppelt sein, dann haben Sie ein besseres Design, das überhaupt keine Vererbung verwendet.
%Vor%Nun würden Ihre abgeleiteten Klassen (die nicht mehr abgeleitet werden würden) wie folgt aussehen:
%Vor%Jetzt können Sie Ihre eine Basisklasse haben, die den DatabaseContext verwendet, und Ihre abgeleiteten Klassen sind nicht mehr davon abhängig.
Alle drei Wege 1. Contstructor, 2. Setter und 3. Interface Injection hat ihre Vor- und Nachteile, hängt davon ab, welche Situation man benutzt. Wenn ich an deiner Stelle wäre, wäre ich mit Setter gegangen, obwohl Schnittstelle auch eine gute Wahl sein kann.
Bitte Sie, diesen Artikel durchzugehen Ссылка
Tags und Links .net c# dependency-injection inversion-of-control