Ich entwickle eine Klassenbibliothek, die in einer Reihe von verschiedenen Webanwendungen verwendet wird und möglicherweise sogar als Open-Source-Projekt zur Verfügung gestellt wird. Es gibt mehrere Punkte, an denen ich IoC verwenden möchte, aber ich möchte nicht, dass die Benutzer der Klassenbibliothek eine bestimmte Implementierung verwenden müssen. Was ist der beste Weg, diese Bibliothek so zu gestalten, dass sie die Vorteile von IoC bietet, aber keine Abhängigkeiten von einem IoC-Framework?
Diese Bibliothek enthält insbesondere ASP.NET MVC-Controller, die Abhängigkeiten von verschiedenen Dienstschnittstellen haben. Ich verstehe, dass ich eine IoCControllerFactory erstellen kann, aber ich bin nicht sicher, ob dies der beste Ansatz ist, da einige Benutzer nicht in der Lage sind oder wollen, dies in ihrer Anwendung zu verwenden, nur um die Funktionalität meiner Bibliothek zu erhalten.
Übergeben Sie die Eigenschaft im Konstruktor für einfache Szenarien.
Verwenden Sie für komplexere Fälle eine Ioc-Container-Schnittstelle, stellen Sie eine Standardimplementierung bereit, aber machen Sie sie so einfach, dass sie mit jedem Contianer implementiert werden kann.
CommonServiceLocator ist eine solche Art von Schnittstelle.
Bearbeiten:
Ich würde jetzt ein anderes Design vorschlagen, das CommonServiceLocator nutzlos machen würde und die Benutzerfreundlichkeit Ihrer Bibliotheksbenutzer verbessern würde:
Sie wählen den IOC-Container aus, der über alle erforderlichen Funktionen für Ihre internen Bibliotheksanforderungen verfügt, und Sie führen ILM als internen Code aus, damit Ihre Bibliotheksbenutzer ihn nicht sehen können. Benutzer müssen nicht wissen, dass die Bibliothek einen Container verwendet.
Sie müssen dann zwei Haupterweiterungspunkte angeben: Konfiguration - eine Möglichkeit, benutzerdefinierte Implementierung der Abhängigkeiten (z. B. Logger ...) bereitzustellen Fabriken - Wenn Ihre Bibliothek das Objekt des Benutzers instanziieren muss, können Sie eine Fabrik angeben, damit Ihre Benutzer sie aktivieren können. Auf diese Weise können sie ihren eigenen Container verwenden, um ihre Objekte zu instanziieren und zu injizieren.
Ich habe zwei vollständige Blogposts über dieses Design gemacht:
Wenn die Anzahl der Abhängigkeiten ziemlich klein ist, können Sie sie einfach über den Konstruktor übergeben. Auf diese Weise haben Ihre Kunden die vollständige Wahl, wie Sie Ihre Objekte erstellen.
Eigenschaften / Setter oder benutzerdefinierte Initialisierungsobjekte sind alternative Möglichkeiten und decken andere Bereiche im Designspektrum ab.
Tags und Links .net asp.net inversion-of-control