M-V-VM
Happy New Year! Hope 2009 is going well for everyone so far. Sorry for the lack of updates on the site. I was busy for the past few months preparing for Jing Pro’s release, but [unfortunately] most of my development was not WPF related.
Also, I have been learning Cocoa and iPhone development during my free time, and hope to blog about my experience migrating to Mac development in the coming weeks.
Now that I am somewhat familiar with Mac development, one aspect that I’ve really become endeared to is how Apple adheres to the MVC pattern – it’s really convinced me it’s a saner way to make stable, decently maintainable code. This prompted me to start thinking about how to follow MVC in WPF development.
Luckily I didn’t have to figure anything out. Karl Shifflett, one of the guys who makes Mole, has a series of posts on a variation of MVC called M-V-VM. M-V-VM stands for Model-View-ViewModel. From what I understand, like MVC, it is a clean way to separate the logic for the UI and your business/data models. The View would be represented by your XAML, the Model is still your data/business stuff. In place of the Controller is the ViewModel, which provides an abstraction of the Model. This is accomplished by exposing properties, implemented with IPropertyNotifyChanged, and commands that your XAML files bind to. The ViewModels then, become the main agents in manipulating your data models. I likes!
Theoretically, this virtually eliminates the need for code-behind logic, freeing UI designers to not have to write code, makes unit-testing because all the logic and behavior has been isolated from the XAML and rendering related objects. Another nice benefit is eliminating almost all value converters, since your XAML would bind directly to properties in the ViewModel. I would love to try this on my next project, but until then Karl has a nice diagram summarizing M-V-VM here:
http://karlshifflett.wordpress.com/2008/11/08/learning-wpf-m-v-vm/
