Ayant travaillé avec le MAF (Managed Addin
Framework ou System.Addin), j’ai découvert avec .Net 4 que MS avait introduit le MEF
(Managed Extensibility Framework ou System.ComponenentModel.Composition), anciennement
disponible comme extention du Framework sous CodedPlex.
Le but n’est évidemment pas de démontrer les deux implémentations, mais comprendre
pourquoi MS nous tends les bras afin que nous embrassions MEF, en lieu et place de
tout autre IoC (Inversion Of Control, ex : Unity, StructureMap…)
L’idée de MEF est de proposer un catalogue contenant les metadata des composants,
composant qui exposeront leurs comportement à votre application (et donc l’étendront).
L’exemple de Glenn Block est un composant (A) annonçant « j’ai une barre d’outil »
et un composant (B : généralement votre application) annonçant « j’ai besoin d’une
barre d’outil). Le composant A export son comportement et le composant B l’importe.
MEF offre un mécanisme d’import/export :
• On marque des classes, variables, etc. avec l’attribut [Import].
Cela indique à MEF « Je peux être étendu »
• On marque ensuite des classes, variables, etc. avec l’attribut
[Export]. Cela indique à MEF « Je suis une extension »
Le MEF se charge ensuite de surcharger la classe, variable, etc. de type [Import]
par sa pendant [Export].
Les intérêts principaux du MEF sont :
• La découverte des extensions depuis plusieurs sources (assembly
courant, assembly ciblée, répertoire, …)
• Les Metadata : possibilité de décorer son code avec des attributs
• La facilité d’implémentation (trois tiers : host (Import), contract
et add-in(Export))
Quant à MAF, l’idée est de proposer un mécanique permettant de faire communiquer votre
application et les add-in de manière découplé et bi-directionnelle.
MAF offre la mécanique pour la mise en place d’add-in, soit les 7 tiers (host, vue
host, adaptateur host, contract, adaptateur add-in, vue add-in, add-in)
Les intérêts principaux du MAF sont :
• La gestion des versions. Le découpage en plusieurs tiers (communication
pipeline) permet la mise en œuvre de multiples versions d’add-in, sans casser la compatibilité
ascendant/descendante.
• La notion de bac à sable. L’add-in est isolé de son hôte et peux
donc s’exécuter dans son propre domaine applicatif. Tout erreurs de l’un des deux
composant n’as pas d’impact sur le fonctionnement de l’autre
• Le chargement est fait au vol, même si la compilation a déjà été
faite (JIT). Cela signifie que l’on peut ajouter un composant add-in à n’importe quel
moment de l’exécution de l’application, celui-ci sera chargé.
Finalement, je constate que les deux méthodes sont complémentaires et peuvent cohabiter
sans problèmes dans la même solution.
