“View Model” – the movie, cast your vote.

Star Wars Script by Richard Moross.


No we’re not actually making a movie about View Model. If we were I am sure we’d get a low turn-out. 🙂 However it did get your attention.

What we are doing is some serious exploration into how we can help from a platform perspective folks that are implementing ViewModel (AKA Model-View-ViewModel  AKA Presentation Model)  in their Silverlight and WPF applications.

In the sense of a movie production, we’re in the script-writing phase. Here’s the general background.

Why is ViewModel important?

There have been many a post on the importance of ViewModel as a pattern and the benefits it brings. In that there is little disagreement that it benefits both developers and designers.

For developers it allows them to have clean separation of presentation logic from the UI rendering, thus making the app easier to maintain. It removes code from the code-behind that often makes the UI logic difficult to test.

For designers it provides a way for a designer to completely change the look of the UI in a tool such as Expression Blend, without breaking the application functionality. Furthermore it gives the designer freedoms beyond simple look and feel, to actually decide which data elements are exposed, as well as defining the interactions between the UI elements through commands and attached behaviors.

The debate over roles

Although the benefits of ViewModel are known, there’s quite a lot of debate both inside and outside Microsoft on the roles the developer and designer play in developing applications that use the pattern.  This runs the spectrum from the designer having complete control of every aspect of the UI,  to the development team having more of a tight handle on the UI components, and the designer being responsible for skinning. In either case there are tradeoffs.

What is important to you?

What is your experience with ViewModel today?

  1. Where does the platform help,? Where does it hinder?
  2. What can we do in the platform to make life easier?
  3. What role do developers / designers play in your application of ViewModel.

Like any movie, we need to touch on the right nerves in order to make it a box-office hit. We need your feedback so we can complete the script.

Thanks for your help

Comments (2)

  1. From the MVC variants, my team uses MVVM exclusively, and I have about 18 months experience with it in total.

    In every project where my team has used MVVM, we have built considerable infrastructure to support our own flavour.  The largest issues that we battle where I feel we either don’t get enough framework support, or the wrong  sort of support I’m looking for are as follows

    0) Supporting editable/mutable view model scenarios

    1) Business object to view model translation or auto-binding

    2) Binding-oriented programming from code

    3) Tooling to provide certain types of compile-time or runtime generated code

    Honestly, I like the way my teams have attacked MVVM and the various supporting infrastructural components we’ve put in place. I can’t think of any particular parts of "the platform" which hinder our strategies, right now. All aspects of WPF, in particular Dispatcher, attached properties (in behaviours), and general binding, have aided greatly, but there’s still room for more assistance.

    Where I haven’t been able to spend enough time to implement my ideas, and where I think huge benefits are going to pay off, are those of #3 above.

    With respect to roles, my team employs designers do the views, and the developers do the view models (since they know the infrastructure best) and the two groups work as closely as they can. Sometimes, the process doesn’t execute as hoped, and designers start doing "mock" view models to support their views and allow them to build more functionality. Sometimes, developers are more aware of certain attached behaviours that can be utilised for styling, and try to share these with the designers. So, there’s a lot of give and take.

    Hope this helps!

Skip to main content