Pieces required for a usable MVVM Framework

As my company migrates towards the .NET framework from VB6, it looks like we are going in the direction of WPF (my boss is in love with the Office-style Ribbon control). I've been working to mock one of our VB6 applications in WPF and decided to experiment with MVVM at the same time. I'm being discouraged from using an existing MVVM framework, so I guess I need to write my own. The biggest concern right now seems to be a method for registering and managing all my views from a central spot - a man开发者_如何学Cager class - but I'm not exactly sure how to implement this. I see article on IoC and ServiceLocator but have a are time putting those ideas to use.

Does anyone have suggestions on the features and patterns that I should be implementing to make a very lightweight, but serviceable MVVM framework? Aside from an existing framework, what existing code resources would you use to help progress this a project like this?

I highly suggest that you watch the "Build your own MVVM Framework" presentation by Rob Eisenberg the creator of the Caliburn framework. He takes you through the main aspects needed for the foundation of your MVVM Framework. Also IMHO Caliburn is one of the best 100+ "MVVMish" frameworks out there. It has a lot of fresh ideas and nice implementation details. There is also the Calibrun Micro framework which is a stripped down more lightweight version of the full framework and is a good stop for studying how things could be done.

I would also suggest, that you don't go too tunnelvisioned on MVVM. Even in WPF there are common scenarios that are better handled using other patterns like MVC, MVP. Infact Caliburn uses all of these patterns. So actually, it really doesn't do it justice calling it a MVVM framework.

I've just begun using the following interfaces to produce a lightweight MVVM framework designed to be introduced control-by-control into an existing application.

public interface IView<C>
    where C : class
{
}

public interface IView<C, VM> : IView<C>
    where C : class
    where VM : IViewModel
{
    IDisposable Bind(VM viewModel);
}

public interface IViewModel : INotifyPropertyChanged
{
}

public interface IViewModel<M> : IViewModel
    where M : class
{
    IView<C> Bind<C>(M model) where C : class;
    IView<C> Bind<C>(string key, M model) where C : class;
}

public interface IViewModel<VM, M> : IViewModel<M>
    where VM : IViewModel<VM, M>
    where M : class
{
}

The following interfaces are an example Person model and view model.

public interface IPerson : INotifyPropertyChanged
{
    string Name { get; set; }
    DateTime? Dob { get; set; }
}

public interface IPersonViewModel : IViewModel<IPersonViewModel, IPerson>
{
    string Name { get; set; }
    DateTime? Dob { get; set; }
    int? Age { get; }
    string Title { get; }
}

And the view implementation, using data binding only, looks like this:

[Factory(typeof(IView<Control, IPersonViewModel>))]
public partial class PersonView : UserControl, IView<Control, IPersonViewModel>
{
    public PersonView()
    {
        InitializeComponent();
    }

    public IDisposable Bind(IPersonViewModel viewModel)
    {
        this.personViewModelBindingSource.DataSource = viewModel;
        return Disposable.Create(() => this.personViewModelBindingSource.Dispose());
    }
}

Now, to use all this I just have the following code:

var personM = context.Resolve<IPerson>();
var personVM = context.Resolve<IPersonViewModel>();
var personV = personVM.Bind<Control>(personM);

var personC = personV.AsControl();
personC.Dock = DockStyle.Fill;
this.panel1.Controls.Add(personC);

I'm using dependency injection to resolve instances of my model, view model & view. The view model's Bind method resolves for the view. All of this is strongly-typed and allows us to write view models that can be used with Windows Forms, WPF & Silverlight.

I hope this is enough for you to work with.

From your words, I'm guessing that your problem is not MVVM, but a navigation problem.

When I started I had the same problem, and was unsure how to implement the creation of views and navigate between them.

Take a look at the Magellan Framework. It does navigation and much more.

I think that it's a fine idea to build your own MVVM framework.

I think that it's a less fine idea to do that without examining the other MVVM frameworks out there, investigating what tools they include, and understanding their design. It's not a whole lot of work to build a minimally-useful MVVM toolkit, but it is a lot of work to figure out what tools you need to build.

Also, if you look at the way other developers have tackled some of the problems you think you're facing, you may find that you don't really understand the problem yet.