Reply to comment

MVVM and NavigationModel for Windows Forms

MVVM arose out of WPF data binding, and is not as compelling a patter for Windows Forms. WPF must data bind to properties. MVVM was a way of getting the right properties onto an object to make it suitable for data binding.

Update Controls for Windows Forms can data bind to methods, so a view model is not strictly necessary. You can put any code that you need to in a GetXxxx() event and it will work. The down side is that code in a GetXxxx() event is not testable. For anything but the most trivial of view code, you will want to move that elsewhere.

You could use a view model as your new repository of non-trivial view code. Either construct one in the view, or have one injected into the view. Let the view call its properties and methods to handle Gets and Sets. Then you can construct a view model outside of the view in order to test it.

You will find that most of the view code is trivial. You will get tired of passing all of this trivial code through the view model. So I would expose the model from the view model so that the view can access it directly when no complex logic is necessary. This is something I never do in WPF or Silverlight.

As for the navigation model, it is simply a model that is not persisted. It records the user's point-of-view as they navigate through the application. Things like UpdateListBox.SetSelectedItem() should write to the navigation model, and then other controls can read from it.

I haven't written up an MVVM sample for Windows Forms because the pattern doesn't always apply. My simple examples don't require a view model, and adding one would just clutter them. But for complex Windows Forms applications, I have introduced view models and navigation models.


By submitting this form, you accept the Mollom privacy policy.