it-swarm.com.de

Sollten .NET Core-Klassenbibliotheken ihre eigenen Implementierungen registrieren?

Unser Team hatte kürzlich große Schwierigkeiten zu entscheiden, ob es eine gute Praxis für die .NET Core-Klassenbibliotheken ist, ihre eigenen Implementierungen zu registrieren, indem es IServiceCollection-Erweiterungsmethoden wie AddMyServices () bereitstellt.

Mein Punkt war, dass es gut ist, dies zu tun, weil:

  • Die Anwendung der obersten Ebene muss nicht alle Details der zugrunde liegenden Bibliothek kennen, die sie verwenden wird.
  • Die Anwendung der obersten Ebene (normalerweise die Startklasse) ist nicht mit Verweisen auf alle Namespaces verschmutzt, die zum Registrieren ihrer Implementierung erforderlich sind.
  • Wenn die Anwendung der obersten Ebene eine eigene benutzerdefinierte Implementierung einiger in der referenzierten Bibliothek definierter Schnittstellen bereitstellen möchte, kann sie dies dennoch tun. Die .NET Core-Abhängigkeitsinjektion ermöglicht mehrere Registrierungen.
  • Wenn mehr Anwendungen auf diese Klassenbibliothek verweisen, müssen Sie keinen Block von z. AddTransient-Zeilen zu jeder Anwendung.

Gegenargumente waren:

  • Einige Beispielanwendungen verwenden den Ansatz, alle Implementierungen in der Startmethode der obersten Ebene zu registrieren.
  • Der obige Ansatz wird nur für Features verwendet (er erzeugt jedoch semantische Zweifel daran, was als Feature bezeichnet werden kann und was nicht). Die Klassenbibliothek kann die von ihr implementierten Features benennen und separate AddFeatureXYZ () -Methoden in der IServiceCollection-Erweiterungsklasse bereitstellen.
  • Die Verwendung der Erweiterungsmethode AddService (), die alle von ihr bereitgestellten Implementierungen registriert, kann sich auf die Leistung des DI-Containers auswirken. Dies ist sinnvoll, wenn bestimmte Klassenbibliotheken viele Implementierungen bereitstellen, aber nur wenige verwendet werden. Ein Entwickler hat jedoch weiterhin die Freiheit, AddServices () aufzurufen oder nicht.

Ich wollte mehr erfahrene .NET Core-Entwickler nach ihren Ansätzen mit allen Profis fragen, die mir vielleicht fehlen. Wenn es starke Argumente für die Verwendung des zweiten Ansatzes gibt, den ich hier nicht aufgeführt habe, würde ich ihn sehr gerne kennenlernen.

PS. Diese Frage wurde aus StackOverflow verschoben, da sie als meinungsbasierter markiert wurde. Meiner Meinung nach berührt es die Grundprinzipien der objektorientierten Programmierung, und es geht nicht darum herauszufinden, welche Mehrheit der Entwickler wählt, sondern darum, warum jemand einen Ansatz gegen den anderen bevorzugt.

Danke, Radek

7

Die ASP.Net-Kerndokumente empfehlen dies

Jede Services.Add {SERVICE_NAME} -Erweiterungsmethode fügt Services hinzu (und konfiguriert sie möglicherweise). Beispielsweise fügt services.AddMvc () die Dienste hinzu, die Razor Pages und MVC benötigen. Wir empfehlen, dass Apps dieser Konvention folgen. Platzieren Sie Erweiterungsmethoden im Microsoft.Extensions.DependencyInjection-Namespace, um Gruppen von Dienstregistrierungen zu kapseln.

Aber ich nicht.

Eines der nervigsten Dinge beim Konfigurieren von Plugins ist der Versuch, die Erweiterungsmethode zu erraten, mit der sie konfiguriert werden sollen. Oder ich sollte sagen, die Version, die Sie als Namen haben, scheint sich zwischen Versionen und Frameworks zu ändern

Zweitens machen diese aufgerollten Registrierungsmethoden häufig nicht alle Dinge verfügbar, die Sie möglicherweise für die zugrunde liegenden Dienste überschreiben oder konfigurieren möchten. Der springende Punkt des Service Managers ist, dass Sie Abhängigkeiten bei Bedarf ersetzen können, aber die Erweiterungsmethode, die dies für Sie tut, kann dies verhindern.

Aber vielleicht am wichtigsten ist, dass diese Konvention noch nicht in Kraft getreten ist. Es scheint einige konkurrierende Philosophien zu geben, wenn es um startup.cs und program.cs geht. Wenn Sie nur eine Methode unterstützen, sind Sie auf der falschen Seite.

Ich würde die Erweiterungsmethode bereitstellen, jedoch in einem separaten optionalen Paket. Ermöglichen Sie Benutzern, die Komponenten manuell zu registrieren, wenn sie möchten, oder verwenden Sie die Erweiterungsmethode für eine Standardeinstellung.

4
Ewan