De manière optimale CMS 12 – Injection de dépendance (DI) – StructureMap vs ASP.Net Core

Si vous effectuez une mise à niveau vers Optimizely CMS 12, l’une des modifications les plus importantes à prendre en compte est la modification du framework Dependency Injection (DI). Les versions antérieures d’Optimizely CMS avaient leur propre infrastructure d’hébergement DI qui prenait en charge d’autres implémentations DI concrètes, comme StructureMap. Avec CMS 12 et ASP.Net Core, le framework DI est intégré au système. Nous pouvons toujours enregistrer et utiliser d’autres implémentations tierces, mais la recommandation est d’utiliser le framework DI intégré.

Alors, comment mettre à niveau un site CMS 11 existant, qui utilisait intensivement StructureMap pour DI, vers CMS 12 et le framework DI intégré, étant donné que StructureMap est en cours de suppression ?

Regardons quelques cas d’utilisation :

1. Enregistrement de la mise en œuvre concrète

Avec Optimizely CMS et son framework DI, nous n’avons enregistré que des implémentations d’interface et non des classes concrètes. Mais avec le DI d’ASP.Net Core, nous devons également enregistrer des classes concrètes. Par exemple, si nous avons une classe comme

Nous devrons l’enregistrer explicitement dans notre conteneur IOC :

2. Inscription des délégués

Si une implémentation concrète est injectée en tant que délégué, alors, comme ci-dessus, son délégué doit également être enregistré :

3. Passage des paramètres du constructeur avec DI

Parfois, nous avons des classes avec des constructeurs où ils injectent d’autres services pour une utilisation ultérieure dans la logique. Maintenant, lorsque nous enregistrons ces classes dans notre conteneur IOC, il ne suffit pas d’enregistrer les noms. Parce que dès que ces références devront être créées, le compilateur recherchera les classes injectées sur le constructeur et ne pourra pas les résoudre. Dans la mise en œuvre de CMS 11, StructureMap a contribué à ces derniers. Voyons avec un exemple :

Disons que nous avons une configuration d’implémentation ILoggerFactory personnalisée comme celle-ci :

Cela injecte la classe LoggingConfiguration d’en haut dans le constructeur. Avec StructureMap, nous fournissions le paramètre Type à ce constructeur comme ceci :

Avec le DI d’ASP.Net Core, cela serait réalisable en faisant quelque chose comme ceci :

Quelques faits intéressants à noter dans la nouvelle inscription DI :

• Nous utilisons un espace de noms appelé Microsoft.Extensions.DepenedencyInjection. Cela nous permet d’utiliser System.IServiceProviderSystem.IServiceProvider s’opposer à obtenir des services précédemment enregistrés via le GetRequiredService() appeler et les utiliser pour d’autres enregistrements de service. Dans notre exemple ci-dessus, nous l’utilisons pour fournir l’objet LoggingConfiguration au constructeur LoggerFactory.
• L’autre est l’utilisation des extensions. Comme vous notez le surligné épiServices ci-dessus, au lieu de nous inscrire directement sur context.Services, nous nous inscrivons sur un ServiceCollectionExtension Au lieu. La raison en était que les appels Add sur context.Services sont ambigus entre Microsoft.Extenesions.DependencyInjection et Episerver.ServiceLocation et qu’il n’y a aucun moyen de faire la distinction entre ceux sur les appels directs.

Alors maintenant, la logique ci-dessus nous permet d’enregistrer un service avec une durée de vie spécifique et nous permet de lui transmettre des paramètres de constructeur.

4. Enregistrement de plusieurs implémentations du même type

Parfois, notre logique nécessite une interface qui peut être implémentée de plusieurs manières différentes pour une utilisation dans différents scénarios. L’enregistrement de tels services nécessite une logique supplémentaire, comme si nous utilisions simplement l’approche standard et enregistrions toutes les classes sur la même interface, seule la dernière est réellement sélectionnée à chaque fois que l’interface est référencée, ce qui n’est donc pas assez efficace. Comprenons avec un exemple :

Scénario 1 : interface normale avec plusieurs implémentations

Mode d’enregistrement StructureMap :

Équivalent .Net Core DI :

Scénario 2 : interface générique avec plusieurs implémentations et types d’attributs génériques

Façon StructureMap :

Équivalent ASP.Net Core DI :

Nous pouvons le faire de la même manière que le scénario 1, mais cela fonctionne pour les types génériques ouverts ou les types génériques fermés avec des types Argument fixes. J’avais des scénarios où mes arguments de type générique étaient également décidés au moment de l’exécution pour différentes implémentations, c’est donc ce qui a fonctionné pour eux.

5. Inscriptions nominatives

Prenons l’exemple de la logique basée sur les événements. Nous avons différents événements, même dans le contexte du CMS, et il y a des cas où nous devons prendre différentes actions par événement dans un contexte commun, comme l’indexation ou la recherche. Alors, comment enregistrer plusieurs implémentations basées sur des événements d’une seule interface afin que le service correct puisse être utilisé pour l’événement correspondant ?

Nous utilisons ici le concept d’enregistrement nommé. Il lie les enregistrements de service aux noms, dans ce cas les noms d’événements et les utilise pour mapper le bon appel ultérieurement.

Voici comment StructureMap nous a permis d’y parvenir :

Et voici son équivalent ASP.Net Core DI :

En gros, vous enregistrez d’abord toutes les implémentations concrètes, puis mappez l’implémentation de l’interface sur la bonne en fonction de la clé, qui dans notre cas est le nom de l’événement.

Ce n’est peut-être pas la liste complète et ce ne sont pas les seuls moyens d’atteindre le résultat final. J’ai moi-même rencontré différentes approches sur différents forums et messages et je peux dire que c’est certainement un peu d’essais et d’erreurs, pour ceux d’entre nous qui n’ont pas trop d’expérience avec la façon de faire d’ASP.Net Core. J’ai dû parcourir plusieurs endroits différents pour aider à traduire chaque cas d’utilisation individuel, alors j’espère que ce guide unique sera utile pour les autres sur le même chemin.