I. Introduction▲
I-A. Qu'est-ce que MEF▲
Le Managed Extensibility Framework (MEF) simplifie la création d'applications extensibles. MEF offre des capacités de découverte ainsi que de composition que vous pourrez exploiter afin de charger des modules pour vos applications.
I-B. Quels sont les problèmes que MEF peut résoudre▲
MEF propose une solution simple au problème d'extensibilité lors de l'exécution. Jusqu'à présent, les applications voulant implémenter un modèle de plugins devaient créer leur propre infrastructure. Ces plugins étaient souvent spécifiques à l'application et ne pouvaient donc être réutilisés dans d'autres applications.
- MEF fournit une approche standard, dans laquelle l'application hôte s'expose elle-même et consomme des modules externes. De par leur nature, les modules ou extensions peuvent être réutilisés dans différentes applications. Toutefois, une extension pourra être utilisée de façon spécifique par chaque application. Les extensions peuvent également dépendre les unes des autres et MEF s'assurera qu'elles soient connectées entre elles dans le bon ordre ;
- MEF offre plusieurs approches de découverte afin que votre application localise et charge les extensions disponibles ;
- MEF permet de d'ajouter des informations supplémentaires (métadonnées) aux extensions, facilitant ainsi le filtrage et la recherche.
I-C. Comment fonctionne MEF▲
Grosso modo, le coeur de MEF est composé d'un catalogue et d'un container. Le catalogue est responsable de la découverte des extensions tandis que le container va coordonner leur création et satisfaire les dépendances.
- la première chose à connaître est la Composable Part (aussi appelée Part par la suite), qui représente une extension. Une Composable Part offre un ou plusieurs exports, et peut aussi dépendre d'un ou plusieurs services externes dit imports. Une Composable Part gère également une instance, qui peut être une instance d'un type donné (l'implémentation MEF par défaut). Néanmoins, MEF est extensible et des implémentations supplémentaires de Composable Part peuvent être créées tant qu'elles respectent les contrats d'Export/Import ;
- les exports et les imports ont chacun un contrat. Les contrats sont les ponts entre les exports et les imports. Un contrat d'export peut consister à fournir des métadonnées qui pourront alors être utilisées pour le filtrage ou la découverte. Par exemple, cela peut indiquer une capacité spécifique offerte par l'export ;
- les containers MEF interagissent avec les catalogues pour avoir accès aux Parts. Le container lui-même résout les dépendances des Parts et expose les Exports au monde extérieur. Vous êtes libre d'ajouter directement des Parts au container si vous en avez envie ;
- une Part retournée par un catalogue sera probablement une extension de votre application. Elle peut avoir des dépendances (Import) sur des composants proposés par l'application hôte et peut également fournir des fonctionnalités (Export) ;
- l'implémentation de MEF utilise les attributs pour déclarer les exports et les imports. Cela permet à MEF de déterminer quels Composable Parts, imports et exports sont disponibles.
Schéma explicatif :
I-D. Vue d'ensemble de l'architecture▲
Le design de MEF peut être divisé en trois couches distinctes. La couche Container, qui contient la plupart des API publiques disponibles pour l'utilisateur ; la couche Primitives, qui fournit une couche d'abstraction, permettant ainsi à MEF de ne pas être fortement lié à une seule approche de découverte ; et enfin la couche d'implémentation par défaut de la couche Primitives, appelée Attributed Programming Model, qui repose sur les types et les attributs pour la découverte et la définition des imports/exports.
La couche Container n'a pas de dépendances sur l'Attributed Programming Model, au contraire elle fonctionne uniquement avec les abstractions fournies par la couche Primitives. Cela rend ainsi possible le développement d'un modèle de programmation complètement différent, et qui peut par exemple fonctionner avec le modèle de programmation par défaut.
Le container représente le coordonnateur ainsi que le constructeur de la topologie ExportProvider. Le set d'instances d'ExportProvider utilisé par l'instance d'un container est chaîné, donc les instances peuvent se requêter entre elles lors de la phase de satisfaction de dépendances. Vous pouvez aussi implémenter un ExportProvider personnalisé afin d'exposer des exports de n'importe quelle source, comme WCF, un Container IoC, Remoting.
Un livre blanc (« Hosting the .NET composition primitives », disponible dans la partie « Liens » de cet article) décrit comment les Primitives peuvent être utilisées indépendamment de MEF.