Dependency Injection - Wann-Eigenschaft verwenden, Injektion
Ich habe eine Klasse, die einen Konstruktor hat wie diese:
private string _someString;
private ObjectA _objectA;
private ObjectB _objectB;
private Dictionary<Enum, long?> _dictionaryA;
private Dictionary<Tuple<Enum,long?>, long?> _dictionaryB;
public SomeDiClass(string someString)
{
_someString = someString;
_objectA = new ObjectA();
_objectB = new ObjectB();
_dictionaryA = new Dictionary<Enum, long?>();
_dictionaryB = new Dictionary<Tuple<Enum, long?>, long?>();
}
Möchte ich, um die Abhängigkeit der Schöpfung von dieser Konstruktor. In einem ersten Schritt würde ich bewegen die ObjectA und B in Abhängigkeit von der Konstruktoren Parameter zu injizieren Sie über Konstruktor-Injektion. Ich würde gerne auf einen IoC-container für diesen Zweck, das ist, wo ich stecken im moment. Die Frage ist, was mit den classextender und die Wörterbücher. Ich injizieren müssen Sie der Klasse, weil der Inhalt der Wörterbücher wird ein wichtiger Teil von unit-tests.
Wäre es eine gute Idee, um zu injizieren, der string und die Wörterbücher per property-injection (I brauchen Sie nicht in anderen Klassen), so würde ich am Ende mit etwas wie dieses?:
private ObjectA _objectA;
private ObjectB _objectB;
public string SomeString { get; set; }
public Dictionary<Enum, long?> DictionaryA { get; set; }
public Dictionary<Tuple<Enum, long?>, long?> DictionaryB { get; set; }
public SomeDiClass(ObjectA objectA, ObjectB objectB)
{
_objectA = objectA;
_objectB = objectB;
}
Ist es die beste Praxis zu lösen so etwas?
Im Allgemeinen. Das aktuelle Projekt ist in C#, so dass ich würde am Ende mit etwas wie Einheit.
InformationsquelleAutor cb_dev | 2013-09-13
Du musst angemeldet sein, um einen Kommentar abzugeben.
Dependency Injection ist kein Ziel, sondern eine Lösung für bestimmte Probleme. Zum Beispiel, Dependency Injection macht es leicht zu ersetzen Abstraktionen für unit-Tests und macht die Anwendung flexibler, da können Sie tauschen, dekorieren und abfangen Abhängigkeiten, ohne die verzehrende Klasse kennen.
Das bedeutet nicht, dass sollten Sie injizieren jeder Abhängigkeiten eine Klasse hat, da muss er helfen, Sie in die Klasse, die getestet werden, und das system mehr wartbar. So fragt man sich, ob es hilft, aus der Perspektive des testens zu injizieren, diese Wörterbücher von außen oder, wenn es hilft, um Ihre Anwendung flexibler.
Diese Letzte Frage ist schwer zu beantworten für mich, da deine Frage nicht detailliert genug. Aber hier sind einige Hinweise:
Nur Dinge, die Sie wollen in der Regel zu injizieren in einer Klasse werden Dienste und Konfiguration Werte.
Ist ein Dienst, einige Vertrag/Abstraktion/Oberfläche, bietet der 'service'. Dies bedeutet normalerweise, dass der service etwas tun, in Ihrem Namen, wie berechnen Sie die Preise, die Kommunikation mit der Datenbank, cache-Werte, das system wieder Zeit, formatieren Sie Ihre Festplatte 🙂
Einer Konfiguration Wert ist, was es ist; nur einen Wert. Aber Sie brauchen, um es zu injizieren, da es nicht hart codiert in die Klasse, und Sie nicht wollen, die Klasse zu Holen, der Wert selbst von der
ConfigurationManager
zum Beispiel, da würde erstellen Sie eine versteckte Abhängigkeit (auf derConfigurationmanager
) und damit wäre die Klasse schwerer zu testen.Andere Dinge, wie primitive, Nachrichten, DTOs, collection-Typen und Entitäten, und alles, was nicht eine Dienstleistung (business-Logik) und nicht in der Art von unit-Tests, nicht abstrahiert werden und deshalb nicht gespritzt werden. In Ihrem Fall die Wörterbücher ein Teil des internen Zustands der
SomeDiClass
Klasse, nicht ein service Ihrer Klasse abhängt.Wenn auf der anderen Seite, diese Wörterbücher werden verwendet von anderen Dienstleistungen, diese Wörterbücher müssen injiziert werden. Aber man kann nie wollen, um zu injizieren, Z Wörterbuch selbst direkt, da das Wörterbuch selbst ist kein service. Stattdessen müssen Sie erstellen eine Abstraktion, die um Sie herum; etwas, das verbirgt, die Angaben zu diesem Wörterbuch und bietet die Anwendung mit einem service rund um die it.
Dependency Injection is not a goal, but a solution to a particular set of problems
ich denke, der rest wird darauf eingehen 😉Ich Stimme mit Ihrer Erklärung von dependency injection. In der Tat muss ich verspotte die Klassen, die ich will, um zu injizieren (in diesem Fall objA und B). Das Konzept des wrapping-service rund um die Wörterbücher, welche die Klasse mit den nötigen Informationen aus Ihnen heraus scheint eine gute Idee zu sein, danke! Es ist immer noch die Frage auf, wie man injizieren Sie die Zeichenfolge. Würde es einen besseren Weg, um es zu injizieren per property-injection oder sollte ich halten Sie es in den Konstruktoren Parameter, abgesehen von objA und B?
Ich persönlich bin ein fan von verschieben der configuration-Wert aus der constructur (in einer Eigenschaft), denn das macht die DI-Konfiguration viel einfacher (vorausgesetzt, Sie verwenden ein container), aber beachte, dass es tut Ergebnis in zeitliche Kopplung.
Ah vielen Dank für den Hinweis auf die zeitliche Kopplung, es ist eine sehr interessante blog-post. In meinem Fall gehe ich für property-injection, weil es nicht entscheidend, ob der string ist nullOrEmpty, dies ist bereits behandelt in der Klasse. So endlich habe ich am Ende mit einem extra-Klasse, die den Inhalt meiner Wörterbücher, objA und B, die injiziert werden per Konstruktor (Mit einem IoC-container ermittelt werden, um die Objekte) und property-Injektion für die Zeichenfolge.
InformationsquelleAutor Steven
Sollten Sie verwenden, Eigenschaft-Injektion (oder setter-injection) bei der Objekt Erstellung Ihrer Art ist aus Ihrer Kontrolle. Wie die aspx-Seite, HttpHandler, ApiController etc. Für alle anderen Situationen ist es empfohlen ist die Verwendung von Konstruktor-Injektion.
Zur Auflösung der Abhängigkeiten für die aspx-Seite mit StructureMap, verwende ich die folgende Vorgehensweise.
Zuerst erstelle ich eine BasePage-Klasse und verwenden von StructureMap Aufbau () - Methode im Konstruktor der Auflösung der Abhängigkeiten der abgeleiteten Seiten. Code ist unten angegeben:
InformationsquelleAutor Vinod Kumar Y S