What is the best way to separate UI (designer/editor) logic from the Package framework (like Visual Studio Package)

Question

I want to separate concerns here. Create and embed all the UI logic for the Custom XML designer, object model, validations etc in to a separate assembly. Then the Package framework should only register the designer information and ask for a UI Service and everything works magically.

This way I don't need to play with the Package framework (Visual Studio Package) assembly, when I need to modify the UI designer.

This question also applies to anything where you have to separate the UI logic from the Skeleton framework that loads it up, like a plugin.

I have several choices a ServiceProvider model, a plugin model or may be other.

Any samples, suggestions for patterns, links are welcome.

Update 1: What I am looking for is a thought such as - "Does Prism (Composite WPF) fit the bill? Has anyone worked on a project/application which does the separation of concerns just like I mentioned above? etc" (I am still looking out for answers)

Answer 1

What you're asking about seams very much like the separation of concerns that the MVC pattern tries to enforce.

ASP.NET MVC is already out there with a preview 5.

It's mainly for web but I think they are planning on using it also for WinForms, but I'm not sure.

Answer 2

I've created a VSPackage that loads an editor. The Editor sits in a separate assembly and implements an interface that I defined. The VSPackage works with the interface, so any changes I make to the editor (and its assembly) does not affect the VSPackage as long as I don't change the interface.

Answer 3

Hi Vin

I prefer the Model View Presenter pattern

Regards Muse VSExtensions