Ich habe einige globale Komponenten. Ich bin nicht sicher, wie ich sie ins Design bringen soll. Wie:
Einstellungs-Klasse: Es verbindet die anfänglichen Einstellungen des Programms, es könnte app.config (1way), web.config (1way), hart codierte Werte (1way) sein, oder sqldb (2way) hinter den Kulissen.
Sprachkurs: es enthält verschiedene Sprachsets, und wieder könnte ich einige resx-Dateien (1way), fest codierte Werte (1way) oder sqldb (2way) dahinter haben / p>
Erste Frage ist, sollte ich diese Klassen Setter-Eigenschaften in Dependency-Injektion machen (ich benutze Windsor):
%Vor%Oder soll ich ihnen einen Kontext geben:
%Vor%Ich stelle fest, dass es in der .net-Bibliothek einige Komponenten gibt, die ein Umgebungskontextmuster verwenden, z. System.Security.Principal, System.Web.ProfileBase, System.Thread.CurrentCulture ...
Glauben Sie, dass es keinen Schaden anrichtet, meine globalen Klassen wie Einstellungen und Sprache als Kontext-Kontext-Klassen zu definieren? Wenn nicht, warum wird DI bevorzugt? Nützen sie beim Komponententesten mehr Vorteile gegenüber der Umgebung?
Zweite Frage ist, wenn DI besser ist, (ich habe das Gefühl, dass das DI-Muster bevorzugt wird), was ist eine gute Möglichkeit, die vorhandenen Umgebungsklassen wie Security.Principal oder Profile zu übernehmen, um dem DI-Muster zu folgen?
Der Umgebungskontext ist in Ordnung, wenn Sie Funktionen implementieren müssen, die sich über mehrere Ebenen erstrecken. (In Ihrem Fall sagen Sie, dass die beiden Objekte global sind) Diese Funktion wird als crosscutting concerns bezeichnet. Wie Sie bemerkt haben, sind viele Klassen in .NET als Umgebungskontext implementiert, wie zB IPrincipal . Um eine funktionierende Version Ihrer Implementierung von Umgebungskontext zu erhalten, müssen Sie für Ihre Objekte Settings und Language einen Standardwert bereithalten, wenn sie als Umgebungskontext entwickelt werden. Meine Annahme ist, dass Sie einige Standardimplementierungen von ILanguage und ISettings bereitstellen werden, und angesichts der Tatsache, dass Sie sie global verwenden werden, sind sie gute Kandidaten für den Umgebungskontext.
Wie oft planen Sie andererseits, die Objekte zu verwenden, die diese beiden Schnittstellen implementieren? Und, ist die Existenz der beiden Objekte entscheidend, also Settings != null und Language != null ? Wenn Sie wirklich beabsichtigen, sie in einer oder zwei Klassen zu verwenden, und / oder wenn die Existenz der Objekte nicht wirklich wichtig ist, sollten Sie die Setter-Injektion verwenden. Die Setter-Injektion benötigt nicht wirklich einen Standardwert, also kann Ihr Objekt null sein.
Persönlich bin ich kein Fan von Umgebungskontext. Allerdings würde ich es verwenden, wenn es sich um die akzeptabelste Lösung handelt. Im Falle Ihrer Implementierungen würde ich so etwas tun: weil Sie Objekte initialisieren müssen, die die zwei Schnittstellen nur einmal und an einem Ort implementieren, könnten Sie mit dem Umgebungskontext beginnen. Wenn Sie feststellen, dass Sie es an einer sehr kleinen Anzahl von Orten verwenden, denken Sie darüber nach, es als Setter-Injektion zu refaktorieren. Wenn die Existenz von Objekten wichtig ist, denken Sie an Konstruktorinjektion Implementierung.
Tags und Links .net c# design-patterns dependency-injection