Comment utilisez-vous le cadre d'extensibilité gérée?

Je travaille avec MEF depuis environ 2 semaines. J'ai commencé à réfléchir à ce à quoi sert MEF, à chercher pour savoir comment utiliser MEF, et enfin à implémenter un hôte avec 3 modules. Les contrats se révèlent faciles à saisir et les modules sont faciles à gérer.

Bien que le MEF ait une utilisation très pratique, je me demande dans quelle mesure? Je veux dire, est-ce que tout le monde va réécrire les applications existantes pour l'extensibilité?

Oui, cela sonne et est incroyablement impraticable. Rhétoriquement parlant:

• comment le MEF affecte-t-il les tendances actuelles de la programmation?

• avez-vous commencé à chercher des opportunités pour utiliser MEF?

• avez-vous commencé à planifier une réécriture majeure d'une application existante qui pourrait bénéficier de l'extensibilité?

Cela dit, mes questions sont les suivantes:
comment savoir quand planifier un nouveau projet avec extensibilité?
comment saurai-je si un projet existant doit être réécrit pour être extensible?

Quelqu'un utilise-t-il MEF?

Quelqu'un utilise-t-il MEF?

Je travaille sur un projet Silverlight utilisant le modèle MVVM. Nous avons commencé par câbler toutes les machines virtuelles ensemble selon les besoins via des interfaces et une injection manuelle de dépendances (constructeur ou injection de propriété selon les besoins). Cela a commencé à devenir douloureux, et nous avons commencé à utiliser MEF en tant que structure d'injection de dépendances pour exporter certains services utilisés dans les modèles de vue et les importer dans les modèles de vue qui en ont besoin. Fonctionne parfaitement et avec très peu de code.

Oui, il existe des puristes qui diront que MEF n'est pas destiné à l'injection de dépendance et qu'un véritable cadre d'injection de dépendance fera beaucoup mieux. Cependant, MEF est intégré à .NET, ce qui est un gros plus, et c'était suffisant pour répondre à nos besoins.

comment savoir quand planifier un nouveau projet avec extensibilité? comment saurai-je si un projet existant doit être réécrit pour être extensible?

OMI, vous devez toujours séparer les problèmes de manière appropriée et utiliser des interfaces pour permettre aux différents modules de changer indépendamment. Si vous le faites correctement, alors lorsque vous trouvez un besoin d'extensibilité, MEF devrait être facile à ajouter. Mais je ne commencerais pas un projet qui n'avait aucune exigence d'extensibilité et ne mettrais MEF qu'au cas où. J'attendrais qu'il y ait un besoin. Pour les projets existants, si un besoin se fait sentir, j'évaluerais l'effort de recâbler le projet pour utiliser MEF par rapport à des solutions alternatives par rapport à ne rien faire, et voir laquelle gagnerait.

L'erreur que les gens font, et je pense que c'est à cause du nom (Managed Extensibility Framework) est de supposer que MEF n'est pratique que pour l'extensibilité. MEF aborde vraiment trois éléments clés: l'extensibilité, la découverte et les métadonnées. Les deux derniers sont très puissants même pour une application qui ne verra jamais un seul plug-in ou extension.

Ceci est un article que j'ai écrit sur son pouvoir de découverte en tant que conteneur IOC: http://www.informit.com/articles/article.aspx?p=1635818

J'utilise MEF dans la plupart des applications d'entreprise, car cela rend plus rapide et plus facile la création et la maintenance d'applications modulaires dans Silverlight.

Actuellement, j'utilise MEF dans quelques projets qui intègrent le modèle de référentiel.

L'un utilise différents types de référentiels lors des tests unitaires, l'autre projet utilise des référentiels locaux (directement sur DB), distants (WCF) et de test.

Les deux projets peuvent modifier leurs types de référentiel via du code ou une configuration, et sont basés sur des types de métadonnées / Lazy MEF.

À ce jour, les deux projets fonctionnent incroyablement bien.