Nouveautés de la version 1.1¶
Même si la V1.1 est une version mineure de transition, elle apporte son lot de nouveautés et de changement. Nous allons faire un tour des principales nouveautés de cette version et dans quelle mesure vous pouvez les exploiter dans vos projets.
Global¶
Version netstandard¶
Une version netstandard2.1 est disponible sur tous les packages pour les projets en .NET Core 3.x. Cela permet de profiter de certaines nouveautés C#8 et certaines parties seront réécrites afin de maximiser cet apport.
MSMQ¶
MSMQ a été déprécié car pas d’usage correspondant aux nécessités des systèmes modernes.
CQELight Base¶
Dispatcher¶
Il existe dorénavant un event (au sens C#) pour pouvoir gérer une collection d’événements dispatchés. Cet event n’est disponible que sur le CoreDispatcher, comme pour ceux qui travaillent de façon unitaire. Pour pouvoir l’utiliser, il suffit de s’abonner à la méthode OnEventsDispatched. Lorsque le code fera un PublishEventRange, c’est cet event qui sera invoqué.
A noter que le TestFramework a été mis à jour pour supporter l’utilisation de cet appel particulier.
Performance du log¶
Il arrive que certaines données à logguer puissent ralentir le flux d’exécution. C’est le cas par exemple lorsqu’on active le mode débug et que l’on veut sérialiser un événement de façon complète pour le tracer. Afin de limiter l’impact sur le déroulement du code, il existe des overloads qui prennent en paramètre une Func<string> qui sera évaluée uniquement si le mode est activé, et permet de retarder l’évaluation (voire de ne carrément pas la faire) si le niveau de log n’est pas actif.
DAL¶
La couche DAL a été réécrite pour permettre une extension et une utilisation plus facile, permettant de couvrir tous les cas. A cet effet, la classe RepositoryBase est dorénavant disponible comme unique point d’entrée à vos données, mais il reste possible (mais non plus nécessaire) d’en faire un héritage pour chacun de vos modèles.
L’utilisation des classes modèles de base n’est d’ailleurs plus obligatoire, mais fortement recommandée pour bénéficier des améliorations natives (comme la suppression logique).
IoC¶
- Afin d’être compatible avec des exigences un peu plus poussées au niveau de l’IoC, il est maintenant possible de
- préciser la durée de vie de l’élément grâce à l’énumération RegistrationLifetime lors d’un enregistrement. 3 sont fournies : Scoped, Singleton et Transient, pour calquer le nommage ASP.NET Core
- définir une stratégie de recherche des constructeurs (si le plugin le supporte) : Full (tous les constructeurs, privés ou protected) ou OnlyPublicCtor (constructeurs publics uniquement, obligatoire pour les enregistrements ASP.NET Core)
- d’avoir un enregistrement de type « FactoryRegistration » qui permet de résoudre un élément du container pendant l’évaluation de la factory
Bootstrapper¶
Event post bootstrapping¶
Un événément (au sens C#) est disponible pour se brancher post-bootstrapping. Il suffit de s’abonner à l’event OnPostBootstrapping de votre instance de Bootstrapper. Cet événement expose un contexte de PostBootstrapping. Retrouvez tous les détails dans la documentation du Bootstrapper : Bootstrapper
Support de MEF¶
L’utilisation de MEF est dorénavant possible, le bootstrapper est capable de trouver seul les plugins pouvant être configurés de façon automatique avec MEF. Afin de ne pas faire mention à une technologie particulière, un flag appelé AutoLoad est utilisé. Seuls les plugins qui marquent le support comme explicite (grâce à l’attribut [Export(typeof(IBootstrapperService))] au dessus de la classe héritant de IBoostrapperService) seront chargés de façon automatique. Les autres seront ignorés.
Classe dédiée pour les options¶
Auparavant, le bootstrapper prenait en paramètres plusieurs booléens pour se configurer. Cette approche, bien que facile, ne respectait pas correctement les bonnes pratiques de l’architecture et du modeling de système. De ce fait, ces constructeurs ont été conservés dans la période de migration, mais une classe a été créée pour héberger la valeur des options de configuration du Bootstrapper. C’est d’ailleurs par cette classe uniquement que l’on peut utiliser l’autoload (voir point ci-dessus).
ASP.NET Core¶
La version 1.1 est la première a supporter nativement et facilement ASP.NET Core. Jettez un oeil à la documentation dédiée pour voir comment l’intégrer : Intégration avec ASP.NET Core
RabbitMQ¶
RabbitMQ a subi une refonte permettant de décrire avec précision une topologie de réseau. La migration est détaillée dans la documentation dédiée (disponible ici : Migration de la V1 à la V1.1) et le détail dans la documentation de l’extension (disponible ici : Bus RabbitMQ).