Diese Frage ist eine Fortsetzung meiner vorherigen Frage: Autofac: Mehrere kontravariante Implementierungen hinter einem Composite verbergen .
Ich versuche, die Grenzen dessen zu finden, was wir mit Autofacs Kovarianz- und Kontravarianzunterstützung tun können. Ich habe festgestellt, dass Autofac ContravariantRegistrationSource nur generische Schnittstellen mit einem einzigen generischen Parameter unterstützt, der mit dem Schlüsselwort in gekennzeichnet ist. Dies scheint die Nützlichkeit dieser Funktion zu begrenzen, und ich frage mich, ob Autofac andere Möglichkeiten hat, die Unterstützung von Kovarianz und Kontravarianz zu erweitern.
Ich muss zugeben, dass ich das nicht wegen eines echten Anwendungsdesigns, an dem ich arbeite, stelle. Ich versuche bewusst, die Grenzen von Autofac wegen der Bildung zu finden.
Betrachten Sie die folgende Schnittstelle:
%Vor%Und die folgende Implementierung:
%Vor%Und die folgende Registrierung:
%Vor%Bei diesem Design und dieser Konfiguration würde ich Folgendes erwarten:
%Vor%Oder lassen Sie mich es abstrakter mit den gegebenen Definitionen sagen:
%Vor%Und die folgende Registrierung:
%Vor%Ich würde erwarten, dass die folgenden Aufrufe erfolgreich sind:
%Vor%Wie können wir das mit Autofac machen?
Ich denke, das ist eine Einschränkung, die wir in Autofac wahrscheinlich nicht überwinden werden, aber es ist interessant zu erforschen.
Wir können contravariant 'resolve' ausführen, da wir bei einem generischen Argument alle Basistypen und Interfacetypen finden können, denen dieses Argument zugewiesen werden könnte. Das heißt, mit string können wir nach Implementierungen für object , IComparable usw. suchen.
In die entgegengesetzte Richtung zu gehen - von einem Argumenttyp zu allen seinen Unterklassen - ist nicht so einfach. Bei object müssten wir nach etwas anderem suchen.
Es kann möglich sein, die Kenntnis der in dem Behälter registrierten Betonkomponenten, z.B. Scannen Sie alle Komponenten nach möglichen Implementierungen und arbeiten Sie rückwärts, aber das ist nicht gut für Autofac, da wir in vielen Fällen auf ein Pull-Modell angewiesen sind, um Komponenten zu erstellen.
Ich hoffe, das ist Denkanstoß, interessiert, um zu sehen, was Sie daraus machen.
Sie haben richtig festgestellt, dass ContravariantRegistrationSource nur Typen mit einem generischen Parameter erkennt. Sehen Sie sich die Quelle an (derzeit bei ca. Zeile 166) sehen Sie diese Einschränkung genau dort. Wenn ich anschaue, wie die Registrierungsquelle zur Bereitstellung möglicher Kandidaten benötigt wird, kann ich verstehen, dass die Aufhebung der Beschränkung eine größere Komplexität bei der Implementierung erfordert.
Ich würde sagen, dass dies nicht beweist, dass Sie die Grenzen von Autofac erreicht haben, nur die Grenzen dieser speziellen Registrierungsquelle. Ich überlasse es als Übung für den Leser, die ContravariantRegistrationSource -Implementierung zu verbessern, und ich bin sicher, dass das Autofac-Projekt mehr als glücklich ist, es wieder in den Kern aufzunehmen.
Tags und Links c# dependency-injection ioc-container autofac covariance