Résoudre les dépendances à l’aide de MEF et du conteneur IoC intégré d’ASP.NET Core

INTRODUCTION

Vous disposez d’un projet Web ASP.NET Core et vous utilisez le conteneur IoC intégré d’ASP.NET Core pour enregistrer et résoudre vos dépendances. Les choses semblent bonnes et parfaites, le framework ASP.NET Core vous facilite la vie en fournissant son conteneur IoC intégré, tout ce que vous avez à faire est de référencer votre projet de contrats et votre projet de service dans votre projet Web ou couche Web et d’enregistrer vos dépendances dans Startup .cs, il injectera les dépendances dans l’application partout où vous en avez besoin.

Enregistrement de la dépendance dans un conteneur de service. ASP.NET Core fournit un conteneur de services intégré, IServiceProvider. Les services sont enregistrés dans la méthode Startup.ConfigureServices de l’application.

Votre fichier Startup.cs ressemblera généralement à quelque chose comme:

Le seul inconvénient de cette approche est que votre projet Web référencera vos contrats de service / abstractions ainsi que votre projet de mise en œuvre de services et votre solution complète devient étroitement couplée. Avec le temps, la liste des inscriptions continuera d’augmenter.

Maintenant, imaginez que vous disposez de plusieurs microservices. Vous voulez remplacer un service par un autre service en gardant les contrats intacts, mais vous devrez tout de même modifier vos dépendances enregistrées dans le fichier Startup.cs et donc recompiler votre projet Web.

Idéalement, la couche Web ne devrait connaître que les contrats et les abstractions, mais pas les implémentations réelles. Mais en enregistrant vos dépendances dans Startup.cs, vous devrez exposer vos implémentations au projet Web.

Dans cet article, nous allons rendre notre projet Web si faiblement couplé que nous pourrions remplacer les anciens services par de nouveaux services en cas de besoin sans recompiler ou modifier la liste des services enregistrés existants en utilisant MEF et IoC intégré conteneur.

Approche basée sur le MEF

Pour découpler notre application, nous prendrons l’aide de MEF. Le Managed Extensibility Framework ou MEF est une bibliothèque permettant de créer des applications légères et extensibles. MEF peut découvrir les composants de notre application en chargeant dynamiquement les DLL et en lisant les attributs des classes. Si vous voulez en savoir plus sur MEF, je vous suggère de visiter la documentation officielle MSDN (https://docs.microsoft.com/en-us/dotnet/framework/mef/).

Se salir la main

Je pense que ce serait plus logique si nous pouvions voir les choses en action. Créons une application ASP.NET Core. Le projet sera un exemple d’API Web.

· Créer un projet API WEB

· Ajoutez trois projets de bibliothèque de classes à la solution.

· On aura tous les contrats nécessaires pour votre application.

· Nous avons divisé nos services en deux projets différents.

· Ensuite, nous ajouterons quelques contrats à notre projet de contrats de service.

· Implémentez les contrats dans la couche Service.

· Ajouter la mise en œuvre du service dans leurs projets respectifs.

· Modifiez le “ValuesController” par défaut en injectant les contrats de service dans le constructeur et en exposant les points de terminaison associés.

Gardez à l’esprit que nous n’avons pas encore enregistré nos dépendances dans le fichier de démarrage.

Enregistrement des dépendances via MEF

Ajoutez un nouveau projet de bibliothèque de classes.

· Ajouter une interface qui exposera certaines méthodes wrapper de «IServiceCollection»

· Ajouter une autre interface sera utilisée pour enregistrer les dépendances.

· Il est temps de mettre en œuvre IDependencyRegister

IServiceCollection se trouve dans la dll Microsoft.Extensions.DependencyInjection.Abstractions.

Il est maintenant temps de voir la magie de MEF. Ajoutez la classe DependencyLoader.

LoadDependencies sera utilisé comme méthode d’extension dans le fichier de démarrage pour indiquer à MEF où charger les dll.

Eh bien, nous y sommes presque, il ne reste plus qu’à résister à nos dépendances dans la couche Service elle-même. Pour ce faire, nous allons implémenter l’interface «IDependencyResolver» et utiliser l’attribut MEF Export pour permettre à MEF de découvrir le code d’enregistrement.

· Ajouter une classe dans le projet ServiceOne & amp; Projet ServiceTwo:

Une dernière chose définit les propriétés de projet des projets de service pour compiler les dll dans le dossier bin web. Les DLL de service seront compilées et enregistrées dans le dossier bin Web.

Dans le fichier de démarrage, nous utiliserons l’extension créée précédemment.

N’oubliez pas d’ajouter de nouvelles entrées dans appsettings.json.

La clé de chemin contient la valeur de l’emplacement des DLL de service. Et ServiceOne porte le nom de «ServiceOne.dll» et ServiceTwo porte le nom de «ServiceTwo.dll».

Exécutez l’application et cliquez sur les URL:

http: // localhost: 56121 / api / values ​​/ data

http: // localhost: 56121 / api / values ​​/ strings


Wow, ce n’est pas beau!

Notre couche Web ne contient que la référence du projet Contracts et ignore totalement la couche de service, donc faiblement couplée.

L’histoire ne passe pas par ici, voyons la vraie magie de tout le travail acharné que nous venons de faire. Nous ajouterons un nouveau projet de service qui implémentera également le «IDummyService1» et remplacerons l’ancien service par un nouveau service sans même recompiler le projet Web. Les services sont désormais connectables à la couche Web sans aucune inscription dans le fichier Startup.cs ni recompilation du projet. Nous allons le rendre configurable en utilisant le appsettings.json.

Construisez le projet complet et recommencez.

Si vous cliquez sur l’URL (http: // localhost: 56121 / api / values ​​/ data), les données de DummyService1 seront chargées.

Arrêtez l’application et modifiez le fichier appsettings.json.

Désormais, les données seront chargées depuis le service NewService sans recompiler ni modifier quoi que ce soit dans un projet ou un fichier de démarrage. C’est la magie dont je parlais.

Code source

Vous pouvez trouver le code source sur GitHub https://github.com/vikas0sharma/sample-for-artice.

Package Nuget

J’ai également créé un package Nuget nommé “vDependencyResolver” pour être directement par les services et les projets Web. Vous pouvez trouver la même chose sur https://www.nuget.org/packages/vDependencyResolver/.

Conclusion

Nous pouvons garder notre architecture propre en conservant les services abstraits sur la couche Web.