Ich verwende derzeit Simple Injector , um Abhängigkeiten in meine Asp.Net Web API-Projekte aufzulösen.
Aus der Dokumentation können Sie es wie folgt konfigurieren:
%Vor%Die wichtigsten Punkte hier sind, die Web-API-Controller zu registrieren und einen benutzerdefinierten Abhängigkeits-Resolver einzurichten.
Ich habe jedoch gerade diesen Artikel von Mark Seemann gelesen, wie man die Abhängigkeitsinjektion in Asp.Net Web Api konfiguriert:
Aus diesen Artikeln habe ich gelernt, dass es eine bessere Option als die Implementierung von IDependencyResolver zum Auflösen von Web-API-Abhängigkeiten gibt.
Diese andere Option besteht darin, eine Implementierung von IHttpControllerActivator zu erstellen, die über den IoC-Container als Adapter fungiert.
Hier ist die Implementierung, die ich mit SimpleInjector programmiert habe:
%Vor% und in der Methode Application_Start habe ich diese Zeile ersetzt:
mit dieser Zeile:
%Vor% Ich würde gerne wissen, ob die Implementierung von IHttpControllerActivator gültig ist und auch, ob dieser Ansatz gültig ist und so gut funktioniert wie der normale?
Ja, Ihre Implementierung ist gültig.
Achten Sie darauf, dass Sie nicht SimpleInjectorWebApiDependencyResolver und SimpleInjectorControllerActivator in derselben Anwendung verwenden. Beide starten ein ExecutionContextScope , was dazu führen kann, dass zwei Bereiche innerhalb der gleichen Webanfrage liegen, so dass sie sich gegenseitig ausschließen.
Ein allgemeiner Vorteil der Verwendung eines Controller-Aktivators gegenüber dem Abhängigkeits-Resolver ist, dass der Abhängigkeits-Resolver-Vertrag den Adapter dazu zwingt, null zurückzugeben, wenn ein Service nicht erstellt werden kann. Dies ist ein sehr häufiges Problem, in das Entwickler geraten, und es führt oft zu dem verwirrenden controller hat keine Standardkonstruktor Ausnahme. Dieses Problem besteht nicht, wenn Sie IHttpControllerActivator verwenden, da der Vertrag Sie zwingt, einen Wert zurückzugeben oder eine Ausnahme auszulösen.
Das Simple Injector Web API-Integrationsprojekt verhindert jedoch dieses Problem mit dem Abhängigkeitsresolver, indem nie null zurückgegeben wird (aber stattdessen eine Ausnahme ausgelöst wird), falls der angeforderte Dienst ein API-Controller ist (und dadurch IDependencyResolver implizit bricht). 's Vertrag).
Ein Vorteil der Verwendung von SimpleInjectorDependencyResolver besteht darin, dass es einfacher wird, Nachrichtenhandler zu erstellen, die innerhalb des Ausführungskontextbereichs arbeiten, da Sie die Erstellung dieses Bereichs durch Aufrufen von request.GetDependencyScope() method auslösen können. Bei der aktuellen Implementierung wird der Bereich zu dem Zeitpunkt gestartet, zu dem der Controller erstellt wird, nachdem Sie die Handler ausgeführt haben. Das Ändern ist nicht so schwer, beinhaltet aber das Ändern des Controller-Aktivators und einen äußersten Handler, der den Ausführungskontextbereich startet (oder wiederum auf einen Abhängigkeits-Resolver zurückgreift, der den Ausführungskontextbereich verwaltet).
Eines der Argumente von Mark Seemann ist, dass es schwierig wird, den Kontext zu übergeben, was ein sehr gültiger Punkt ist, solange Ihr Komponenten benötigen diesen Kontext während der Konstruktion nicht . Dies ist jedoch kein Problem, das bei der Verwendung von Simple Injector auftreten wird, da es ein Erweiterungsmethode , die Ihnen beim Zugriff auf HttpRequestMessage hilft. Obwohl die IDependencyResolver -Abstraktion nicht dafür ausgelegt ist, die kontextabhängigen Informationen zu erhalten, gibt es Möglichkeiten, diese kontextbezogenen Informationen zu erhalten.
In der Vergangenheit haben wir uns für einen Adapter für IDependencyResolver entschieden, hauptsächlich weil dies bei allen DI-Containern üblich war. Ich bedauere diese Entscheidung teilweise, aber die Verwendung von SimpleInjectorDependencyResolver ist normalerweise der einfachste Weg, um Simple Injector in die Web API zu integrieren. Wir haben darüber nachgedacht, auch ein SimpleInjectorControllerActivator hinzuzufügen, aber dies hatte für die meisten Benutzer keinen praktischen Nutzen, während wir dennoch dokumentieren mussten, wann was zu verwenden war. Also entschieden wir uns, bei dem Dependency Resolver Adapter zu bleiben; ein Adapter für den Aktivator ist leicht für jeden, der sie benötigt, erstellt, wie Sie sehen können.
Für ASP.NET Core gingen wir jedoch in eine andere Richtung, und wie Sie in der Dokumentation sehen können, ist das Integrationspaket tatsächlich enthält ein SimpleInjectorControllerActivator out of the box. In ASP.NET Core ist der Controller-Aktivator der perfekte Abfangpunkt, und aufgrund der OWIN-ähnlichen Pipeline kann ein Bereich problemlos um eine Anforderung herum angeordnet werden. Bei ASP.NET Core ist es ratsam, den Controller-Aktivator als Abfangpunkt zu verwenden.
Tags und Links asp.net-web-api c# dependency-injection simple-injector