Version imprimable
Lire l'articleCitation:
Cet article est une traduction autorisée du guide de programmation MEF disponible en anglais sur CodePlex et enrichi de quelques compléments. Il se découpera en trois parties : une introduction sur le Managed Extensibility Framework, une autre centrée sur la découverte et l'utilisation de MEF, tandis que la dernière se penchera sur les fonctionnalités spécifiques à Silverlight.
N'hésitez pas à poster vos commentaires.
Bonjour,
Il semble que MEF soit l'équivalent de Osgi en java : http://stackoverflow.com/questions/7...f-osgi-for-net
Citation:
Compared to OSGi, MEF is built upon "Inversion of Control" and OSGi is not: it (OSGi) will discover new bundle through a different mechanism based on a Life Cycle Layer.
Il semble que ces deux technologies soient similaires, mais je n'ai pas creusé la question.
Et ce n'est pas le but de l'article, qui n'est qu'une découverte de MEF ainsi que sa mise en pratique.
Par contre, si tu creuses tu côté d'OSGI je serais curieux du résultat :D
Avec un peu de chance, dans six mois... :)Citation:
Envoyé par laedit
Intéressant, c'est la mode de sortir de l'instanciation dynamique d'interface ou via un bon vieux Abstract factory pour la gestion de plugins, et de passer par les attributs de classe.
Cependant, je me pose une question existentielle par rapport à ce système :
Imaginons une classe C1 qui possède 2 attributs de classe A1 et A2. Si on demande les classes exportant A1, on aura une instance de C1. Si on demande les classes exportant C2, on aura une autre instance de A1. Y a-t-il moyen de renvoyer la même instance?
Si j'ai bien compris ta question, une 3° classe B1 importerait A1 et A2 et tu souhaiterais que A1 et A2 proviennent de la même instance de C1, c'est bien cela ?Citation:
Envoyé par blbird
Dans ce cas oui, vu que l'instance générée par le système ne peut être que celle obtenue via le constructeur par défaut. Mais si par contre, tu veux que ça soit réellement la même instance, faisant référence au même espace mémoire je n'en suis pas certain. C'est à creuser.
C'est presque ca :)Citation:
Envoyé par laedit
Je parlais de A1 comme attribut de classe, et de A2 comme autre attribut de classe. Si on a une classe C qui utilise A1 et A2, et qu'on récupère une instance de classe C1 en filtrant par A1, et une instance de classe C2 en filtrant par A2, on obtient 2 instances de classes différentes.
Je voulais savoir s'il y avait moyen d'obtenir un singleton la-dessus, ce qui est le cas avec des IOC existants comme StructureMap par exemple.
Je t'avoue que je ne sais pas du tout.
Il faudrait creuser mais le temps me manque en ce moment :?
Quelle usine à gaz pour pas grand chose quand même....
En tous cas, félicitation pour la traduction, elle est excellente.:ccool:
Je suis un peu d'accord sur le côté usine à gaz. J'aime même l'impression que c'est pire qu'Osgi, et c'est pas peux dire. :mrgreen:
Si vous voulez faire des plugins simples, dirigez-vous vers un petit IoC comme StructureMap (il en existe bien d'autres), qui marchent très bien, et en quelques lignes vous aurez un système de plugins basé sur des interfaces. :ccool:
La seule fonctionnalité que vous n'aurez pas, c'est la dépendance des extensions entre elle (encore que cela peut se gérer aussi).
Pour l'avoir testé je ne trouve pas que ce soit une usine à gaz :
Il suffit de définir un contrat (interface), d'ajouter des attributs d'imports/exports, d'ajouter 3 lignes afin de faire les imports et le tour est joué.
Moi je le vois par rapport à un développement industriel. En fait c'est une modularité du code, mais c'est trop abstrait et surtout ça ne résoud pas le problème de l'extensibilité : livrer, certifier, sécuriser.Citation:
Envoyé par laedit
C'est bien beau de faire une extension "hello world". Après de faire des extensions qui peuvent partager des contrats de service sur des app domains différentes...
Pardon j'edite parce que c'est un peu léger pour ce que je dis :
Je trouve que c'est encore très "close to the metal". En fait on plus l'impression de voir un framework qui encapsule l'IOC en essayant de promouvoir des scénarios et une minimisation des contrats, plutôt que de voir un Framework qui apporte des réponses concrête à l'extensibilité des applications.
Voilà pourquoi je trouve que c'est une usinge à gaz. Ca ne fait rien que je ne pourrai faire avec Ninject si je voulais faire en convention, ou avec du Spring par configuration.
C'est vrai qu'Osgi, ça laisse dubitatif, l'abstraction de l'abstraction de l'AOP et de l'IOC.Citation:
Envoyé par blbird
En même temps je dis, les appdomains et la réflection .Net, plus un bon framework IOC, ça permet de faire bien plus ciblé et plus léger.
Pour arriver à avoir une seule instance, il faut jouer sur la "Sharability" de import qui propose une propriété RequiredCreationPolicy qui est de type enum et qui peut recevoir Any, Shared et NonShared. Plus d'infos voir le tuto plus précisément ici.Citation:
Envoyé par blbird
Sinon il y a aussi l'import différé qui te permet non seulement de différer l'import mais aussi d'avoir une seule instance de la Part si aucune valeur n'est définie pour la propriété RequiredCreationPolicy ou si la valeur de cette dernière est NonShared.
Je n'ai pas assez bien compris mais le fait que ça n'apporte rien de nouveau par rapport à des outils existants ne fait pas de lui une usine à gaz.Citation:
Envoyé par B.AF
Peut être que si tu nous donnais des cas d'utilisations où cela peut devenir une usine à gaz ce sera cool :ccool: ?
Pour ma part, je trouve que l'utilisation du framework peut vite devenir une unsie à gaz si :
- on a beaucoup de méthodes, propriétés et champs importés individuellement. On sais que cela peut vite nuire à la maintenabilité de l'application :calim2:
- on y ajoute la découverte de parts privées :oops:
- on a mal géré la sharability des parts ce qui peut entraîner des fuites de mémoires si on ne fait pas gaffe :?
L'extensibilité a toujours existé en .Net : c'est le fait de charger des assemblages et de gérer des domaines d'application.
Le fait de créer des objets et d'exposer des interfaces, c'est l'IOC.
Le fait de pouvoir intercepter et gérer les cycles de vie objet sans intrusion, c'est l'AOP.
Ca reste pour moi un moyen complexe de repousser le moment où il faudra faire du code 'utile'--> On peut tout faire, il suffit de faire une extension.
Me concernant, je ne lui trouve pas d'application concrête, mais si c'est utile à d'autre, je ne dis pas qu'il n'y a pas de bonnes idées dedans.
Bonjour à tous,
Je déterre ce sujet assez vieux pour discuter d'une chose : l'utilisation du shadow copy dans un autre appdomain afin de pouvoir mettre à jour les DLL de plugin à la volée.
J'ai lu beaucoup de sujets concernant MEF, concernant l'utilisation d'un appdomain pour le reload à la volée mais à chaque fois, aucun d'entre eux ne traitaient un sujet comme le plugin embarquant une vue par exemple.
Alors bon, j'arrive à utiliser MEF de façon classique, à récupérer mes vues de plugins et les afficher. Jusque là, tout va bien.
Lorsque j'essaye d'appliquer les différents tutos sur l'utilisation d'un appdomain à part avec l'option shadow copy à true, cela ne fonctionne plus.
J'ai une exception m'indiquant que ma classe de plugin n'est pas serialisable.
Cela provient au moment où je récupère ma vue de mon plugin depuis l'application principale (j'en conclue donc qu'il essaye de passer d'un appdomain à l'autre et c'est ça qui bloque. Jusque là, ça me parait logique).
Ma question est donc la suivante : comment créer un systeme de plugins à partir de MEF pour que l'on puisse embarquer des vues dans chaque plugin et que le programme principal puisse les embarquer et les afficher (tout en gardant en tête que là on parle d'utilisation de shadow copy dont voici un exemple : http://www.codeproject.com/Articles/...ies-On-The-Fly) ?