views:

63

answers:

1

We have a solution with two different projects, one with the requirement that it be done using the .Net 2.0 framework. The other uses .Net 3.5, and we follow MVVM, though I suspect this is less about MVVM than good patterns.

The .Net 2.0 has several different objects (let's say of type Fruit) which could potentially require a different WPF user interface to edit the class property values. For now, I am just working on the first one. The .net 3.5 project is what users actually run and edit with.

My first thought was, when we create the Fruit subclass (Apple, in the constructor have a Func parameter which returns the call to create the editing dialog. The other fruits, which do not have editing dialogs implemented yet, would simply have a Func parameter which returns a "Editing not supported" editor dialog. But Funcs are not supported in 2.0.

My next thought is, to add attributes to the .net 2.0 classes which refer to the .Net 3.5 classes which the .net 3.5 project could then create instances of, using reflection. But this seems messy.

I could create a CreateFruitEditor class in the .net 3.5 project that just checks the Fruit type and creates the appropriate editor window, but that would eventually result in a big multi-line if statement checking types (with the assumption that the fruits are quite different in editing.)

So...the .net 2.0 project classes must somehow inform my .net 3.5 project of what .net 3.5 classes to use for editing the .net 2.0 classes.

+1  A: 

You are mixing concerns here. Treat your .NET 2.0 classes as your Model and wrap or replace them with ViewModels for your views.

Anderson Imes