Dependency Inject (DI) "freundliche" Bibliothek

Ich denke über das Design einer C # -Bibliothek nach, die verschiedene Funktionen auf hoher Ebene enthalten wird. Natürlich werden diese übergeordneten Funktionen mit dem implementiertSOLIDE Klasse Design-Prinzipien so viel wie möglich. Als solche wird es wahrscheinlich Klassen geben, die für Verbraucher direkt und regelmäßig verwendet werden sollen, und "Unterstützungsklassen", die Abhängigkeiten von diesen allgemeineren "Endbenutzer" -Klassen sind.

Die Frage ist, wie die Bibliothek am besten gestaltet werden kann:

DI Agnostic - Obwohl das Hinzufügen einer grundlegenden "Unterstützung" für eine oder zwei der gebräuchlichen DI-Bibliotheken (StructureMap, Ninject usw.) sinnvoll erscheint, möchte ich, dass Benutzer die Bibliothek mit jedem DI-Framework verwenden können.Nicht-DI verwendbar - Wenn ein Benutzer der Bibliothek kein DI verwendet, sollte die Bibliothek dennoch so einfach wie möglich zu verwenden sein, wodurch der Arbeitsaufwand verringert wird, den ein Benutzer benötigt, um all diese "unwichtigen" Abhängigkeiten zu erstellen, nur um an sie zu gelangen die "echten" Klassen, die sie verwenden möchten.

Mein derzeitiger Gedanke ist es, ein paar "DI-Registrierungsmodule" für die allgemeinen DI-Bibliotheken (z. B. eine StructureMap-Registrierung, ein Ninject-Modul) und einen Satz oder Factory-Klassen bereitzustellen, die nicht DI sind und die Kopplung mit diesen wenigen Fabriken enthalten.

Gedanken?

Antworten auf die Frage(4)

Ihre Antwort auf die Frage