Extensibilité des applications

Une excellente session par Yann Schwartz, Architecte technique chez Polom et Sébastien Ros, Chief Software Architect chez Evaluant.

Introduction

Il s'agit de savoir prendre en charge la complexité liée à la gestion d'un système constitué de nombreux morceaux.

Le problème: nos applications sont constituées de nombreuses parties, reposent sur des services locaux ou distants, dépendent d'assemblages tiers (bibliothèques, par exemple pour le traçage), sont exécutées dans différents contextes (notamment de sécurité). Elles sont donc faciles à construire mais difficiles à démêler.

On veut notamment: tester sans dépendances, gérer le cycle de vie des composants, et distinguer les besoins techniques des besoins métier.

Avec un peu de bon sens, on peut imaginer:

• séparer contrat et implémentation, pour que les deux parties ne se connaissent pas
• utiliser des factories, car c'est une mauvais idée que chaque composant fasse comme s'il était seul au monde. On ne fait pas de new directement. C'est le "new new".

Mais il reste un problème, même avec les factories: c'est toujours le composant qui décide quand instancier. Avec l'inversion de contrôle, on définit les interfaces et leurs dépendances, et le système s'occupe de l'instanciation.

Tant qu'à faire, on va aussi généraliser la notion de factories en: enregistrant les dépendances, les résolvant en cascade.

Les frameworks d'IoC sont entre-autres:

• Spring.NET (le plus ancien, venant de Java)
• Castle Windsor
• NInject
• Unity

Unity

Notion de conteneur: c'est lui qui s'occupe de tout. Il est la source unique d'instances. On s'enregistre auprès de lui, et c'est lui ui résoud les demandes de contrats avec au choix:

• Service Locator: c'est l'équivalent des factories, il est un peu tombé en désuettude.
• Injection de dépendance (constructeur ou propriétés).

Le conteneur ajoute quelques notions sympa: singleton/instance, implémentations multiples, interception (par exemple pour ajouter du log, du cache, ...).

On peut écrire la configuration en XML, mais on préfère maintenant plutôt le code vu que ce sont des paramètres peu modifiés.

En Unity, on instancie le Container, et on appelle sa méthode RegisterType ou RegisterInstance (singleton) en lui passant interface et classe. On appelle ensuite sa méthode Resolve pour récupérer un objet sur lequel on peut travailler.

Pour les tests unitaires, cela nous simplifie aussi énormément la vie. Car d'habitude on rencontre un problème dès que nos composants utilisent des ressources telles que le réseau, la base de données, ... Avec l'IoC, c'est très simple: l suffit d'injecter des implémentations vides. On a même des frameworks pour éviter d'écrire les implémentations vides (exemple: Rhino.Mocks).

On a ainsi découplé les composants. Mais il reste à gérer l'interaction entre l'application et le monde extérieur. C'est là que MEF arrive.

MEF, Microsoft Extensibility Framework

C'est le moteur d'extensibilité pour ASP.NET 4.0, Visual Studio 2010, Oslo.

Principe: on utilise les attributs [Import] et [Export] pour mettre en relation fournisseur et consommateur d'interface (c'est de l'IoC). MEF assure la mise en relation, donc le découplage.

Note: on peut exporter des classes entières, mais aussi de simples méthodes sous la forme de délégués.

Pour aller plus loin, on peut trouver des Parts (composants) dynamiquement. Grâce à la classe DirectoryCatalog, on peut même décuvrir les composants dans un répertoire.

Les composants sont paritaires: une Part peut déclarer des Import et des Export.

Conclusion

MEF est simple (utilisation d'attributs), open source, disponible.

Unity a son utilité: MEF permet de découvrir les composants, alors qu'Unity sert à travailler sur un ensemble connu de composants.