Quelle est la meilleure façon de séparer la logique d'interface utilisateur (concepteur/éditeur) de l'infrastructure de package (comme le package Visual Studio)

Question

Je souhaite dissocier les problèmes 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 du package doit uniquement enregistrer les informations du concepteur et demander un service d'interface utilisateur et tout fonctionne de manière magique.

De cette façon, je n'ai pas besoin de jouer avec l'assemblage Package Framework (Visual Studio Package), lorsque j'ai besoin de 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 la charge, comme un plugin.

J'ai plusieurs choix d'un modèle ServiceProvider, un modèle de plugin ou peut-être autre.

Tous les échantillons, suggestions de motifs, liens sont les bienvenus.

Mise à jour 1: Ce que je cherche, c'est une idée comme: «Est-ce que Prism (Composite WPF) correspond à un projet/une application qui fait la séparation des préoccupations comme je l'ai mentionné plus haut? " (Je suis toujours à la recherche de réponses)

Answer 1

J'ai créé un VSPackage qui charge un éditeur. L'éditeur se trouve dans un assembly séparé et implémente une interface que j'ai définie. Le VSPackage fonctionne avec l'interface, donc toutes les modifications que je fais à l'éditeur (et à son assemblage) n'affectent pas le VSPackage tant que je ne change pas l'interface.

Answer 2

Ce que vous demandez sur les coutures ressemble beaucoup à la séparation des préoccupations que le modèle MVC essaie de faire appliquer.

ASP.NET MVC est déjà là-bas avec un preview 5.

C'est principalement pour le web mais je pense qu'ils prévoient de l'utiliser aussi pour WinForms, mais je ne suis pas sûr.

Answer 3

Je préfère le modèle Model View Presenter