Application WPF extensible - MEF, MAF ou chargement simple?

Question

(je sais sur les questions MEF/CRG, mais cela est un problème plus spécifique)

Je veux créer une application WPF qui sera essentiellement un simple complément hôte, l'interface graphique et les paramètres. Tout le travail actuel sera effectué par un ou plusieurs plugin (s). Ils n'ont pas besoin de communiquer entre eux, l'application principale leur enverra des entrées/commandes utilisateur et ils renverront des résultats (par exemple, les éléments d'interface utilisateur WPF à rendre).

Maintenant, puisque le noyau de l'application sera basé sur des plugins, j'ai besoin de choisir un bon moyen de les gérer. Je veux être en mesure de charger/décharger/recharger les à l'exécution (par exemple lorsqu'une mise à jour est trouvée et téléchargée). Ils devraient probablement fonctionner dans leur propre domaine d'application et/ou processus pour la stabilité et la sécurité.

De quelques recherches et expériences, je suis venu à trois options:

• System.AddIn (CRG): Il semble que cela peut faire tout ce qu'il faut. Il y a un pipeline qui permet à plusieurs versions d'API d'être exécutées en même temps pour la compatibilité etc. Mais à moins de manquer quelque chose, j'ai besoin de créer l'API plusieurs fois - vues hôte et plugin, contrat et deux adaptateurs pour le contrat. De plus, il y a peu d'informations et de ressources (par rapport au MEF) et la plupart des articles datent de quelques années. Je suis inquiet que ce soit en train de mourir et préfère ne pas l'utiliser pour un nouveau projet.

• MEF: Celui-ci semble plus simple, mais il se sent aussi comme il y a beaucoup de magie que je ne peux pas contrôler, et les couches ne sont pas séparés autant que dans le CRG. Je veux juste une petite bibliothèque que vous pouvez lier à un nouveau projet, implémenter l'interface et le plugin est fait.

• chargement manuel: La dernière option serait de dossier pour rechercher manuellement .DLLs, la réflexion utiliser pour trouver des classes plugin et créer des instances. Bien qu'il soit faisable, je préfère utiliser un certain cadre de charger manuellement des ensembles, créer processus distinct/appdomain etc.

Donc, ce qui serait le mieux pour ce genre d'application, ou est-il quelque chose que je Avez-vous manqué?

Answer 1

MEF est certainement l'option la plus simple des trois. Il a vraiment été conçu avec ce scénario précis (applications extensibles) à l'esprit.

C'est en fait le mécanisme "plugin" utilisé par Visual Studio, qui est une application WPF. Tout ce que vous devez faire est d'avoir votre "plugin" implémenter une interface ou dériver d'une classe de base connue, et ajouter l'attribut [Export]. Pourvu que son assemblage soit ajouté au catalogue de votre application principale, ce type peut être [Import] édité par l'application principale en une seule étape. Il y a très peu de travail pour faire ce travail.

Ce serait ma recommandation, à moins qu'il y ait une forte raison de choisir une autre option. MAF a plus de support d'isolation, mais est beaucoup plus difficile à utiliser, et la plupart des fonctionnalités d'isolation ne seront pas utilisables dans une application WPF, puisque l'interface utilisateur de WPF ne peut pas vraiment être du code isolé dans tous les cas.