Quel est le meilleur moyen de séparer la logique d'interface utilisateur (concepteur / éditeur) du cadre de package (comme Visual Studio Package)

Question

Je veux dissocier les préoccupations ici. Créez et intégrez toute la logique d'interface utilisateur pour le concepteur XML personnalisé, le modèle d'objet, les validations, etc. dans un assemblage séparé. Ensuite, la structure de package doit uniquement enregistrer les informations du concepteur et demander un service d'interface utilisateur. Tout fonctionne comme par magie.

De cette manière, je n'ai pas besoin de jouer avec l'assemblage de la structure Package (Visual Studio Package), lorsque je dois modifier le concepteur d'interface utilisateur.

Cette question s'applique également à tout ce qui nécessite de séparer la logique de l'interface utilisateur du framework Skeleton qui le charge, comme un plugin.

J'ai plusieurs choix: un modèle ServiceProvider, un modèle de plug-in ou un autre.

Tous les échantillons, suggestions de modèles, liens sont les bienvenus.

Mise à jour 1: Ce que je recherche, c’est une pensée du genre: "Prism (Composite WPF) convient-il à la facture?" Quelqu'un a-t-il déjà travaillé sur un projet / une application qui sépare les problèmes comme je l'ai mentionné plus haut? etc " (Je cherche toujours des réponses)

Answer 1

J'ai créé un VSPackage qui charge un éditeur. L'éditeur siège dans un assemblage séparé et implémente une interface que j'ai définie. Le VSPackage fonctionne avec l'interface. Par conséquent, les modifications apportées à l'éditeur (et à son assemblage) n'affectent pas le VSPackage tant que je ne modifie pas l'interface.

Answer 2

Ce que vous demandez au sujet des coutures ressemble beaucoup à la séparation des préoccupations du MVC . motif tente de faire appliquer.

ASP.NET MVC est déjà disponible avec un aperçu 5 .

C’est principalement pour le Web, mais je pense qu’ils envisagent de l’utiliser également pour WinForms, mais je ne suis pas sûr.

Answer 3

Je préfère le modèle de présentation du modèle .