Was ist der beste Weg, UI (Designer / Editor) Logik aus dem Paketrahmen zu trennen (wie Visual Studio-Paket)

Question

Ich will hier Bedenken trennen. Erstellen und betten Sie alle UI-Logik für die benutzerdefinierte XML-Designer, Objektmodell, Validierungen usw. in eine separate Baugruppe. Dann sollte der Paketrahmen nur die Designer-Informationen registrieren und fragen Sie nach einem UI-Service und alles funktioniert magisch an.

Auf diese Weise brauche ich nicht mit dem Paket Rahmen (Visual Studio Package) Montag zu spielen, wenn ich die UI-Designer ändern muß.

Diese Frage gilt auch für alles, wo Sie die UI-Logik aus dem Skeleton-Framework, das es trennen müssen oben, wie ein Plugin geladen wird.

Ich habe mehrere Möglichkeiten ein Serviceprovider-Modell, ein Plugin-Modell oder andere sein.

Alle Proben, Vorschläge für Muster, Links sind willkommen.

Update 1: Was ich suche ist ein Gedanke, wie - „Prism Hat (Composite WPF) passen die Rechnung Hat jemand an einem Projekt / Anwendung gearbeitet, das die Trennung von Bedenken tut wie ich oben erwähnt etc?“ (Ich bin noch auf der Suche nach Antworten aus)

Answer 1

Ich habe ein VSPackage erstellt, die einen Editor lädt. Der Editor sitzt in einem separaten Baugruppe und implementiert eine Schnittstelle, die I definiert ist. Die VSPackage arbeitet mit der Schnittstelle, so dass alle Änderungen, die ich an den Editor zu machen (und die Montag) nicht die VSPackage beeinflussen, solange ich die Schnittstelle nicht ändern.

Answer 2

Was Sie fragen über Nähte sehr ähnlich wie die Trennung von Bedenken, dass die MVC Muster versucht zu erzwingen.

ASP.NET MVC ist bereits da draußen mit einem Vorschau 5 .

Es ist vor allem für Web, aber ich denke, dass sie über die Verwendung auch für WinForms planen, aber ich bin nicht sicher.

Answer 3

Ich ziehe den Model View Presenter Muster