Geeks With Blogs

News Locations of visitors to this page

Brian Genisio's House of Bilz

Adventures in MVVM Shout it kick it on DotNetKicks.com

I have been spending a lot of time lately thinking about client architecture with Silverlight and to a lesser extent, WPF.  I tend to subscribe to the philosophy that when you make your code testable, you get a lot of other great qualities along with it.  I believe this so strongly that I go out of my way to architect my inherently untestable code in a way that I can, indeed, test it.

Since I have been writing most my code for the Silverlight platform in the past several months, and I wanted very much to write my code test-driven.  I used the Model-View-Presenter pattern (MVP) to implement my view as an interface.  The presenter would hand model objects over to the view and I would bind visual items in my view to the model items.  The presenter would then tell the IView what to do when any real logic came to play.  Over time, however, more and more logic started creeping into the code behind.  I had a lot of data converters to doing my dirty work, blending the code between the model and the view.  The problem is that anything within the IView implementation (aka code-behind) is not easily unit-testable.

organic

As I started to really understand how binding worked in the context of XAML, I found myself wanting to use binding against view-agnostic objects for testability.  Since the view didn’t know anything about the presenter, the only data to bind to was in the model.  Sadly, view-specific data started to creep into model items.  Where ThumbnailData (for instance) was only meta-information that came from my server, it began to gain properties such as Selected and Hidden.  Moreover, what “Selected” means to one part of the UI is different to another part of the UI.

This was not the direction I wanted to go.  In a fit of desperation, a colleague and I sat down and designed a pattern where we had a “ViewState” and a “ViewLogic” class.  “ViewState” was just a set of properties (model data and view properties) that implements INotifyPropertyChanged for the view to bind against and “ViewLogic” manipulated the “ViewState” to add the UI smarts.

The benefits were immediate and obvious.  We started seeing logic that was once in the code-behind move over to the “ViewLogic”.  We immediately received testing benefits.  We could write tests against the “ViewState” as if it were the actual UI.  We even started writing our new features with TDD.  Everything was great!

I was all ready to start blogging about it.  My colleague and I had come up with this fantastic pattern for making testable Silverlight UIs and I wanted to tell the world.  When doing some comparative reading I started seeing the “MVVM” term pop up here and there.  It didn’t take long for me to realize that what we had invented in a bubble was just a subtle variant of the Model-View-ViewModel pattern.  The ViewModel is really just our ViewLogic and ViewState combined into one single class.  It only solidified my belief that this pattern had legs.

Although I sensed some initial skepticism from my team-mates about using the pattern throughout the product, it didn’t take long for them to recognize how important the MVVM pattern would be to our project.  Since adoption our test coverage has skyrocketed with hundreds of useful tests.  The proof is in the pudding.  The vast majority of our bugs that come in have been one of two types of bugs: Missed features or improper binding – two things that the MVVM pattern can’t help prevent.

So, that is how I got so interested in the MVVM pattern.  Because it is relatively new, the community is still working out the best practices.  There is room for experimentation and that can be a lot of fun.  Lets solve the new problems.  Lets push the community in the right direction.  We are already hearing the buzz for Silverlight 3 to contain native support for MVVM (via Prism).  Lets keep this going… and lets have fun doing it!

Posted on Wednesday, May 27, 2009 9:52 PM | Back to top


Comments on this post: Adventures in MVVM – A Testing Story

# re: Adventures in MVVM – A Testing Story
Requesting Gravatar...
Hi Brian,

Thanks for sharing your knowledge. But have you posted article on the implementation of MVVM pattern? If not, can we expect this in near future? Because bunch of articles in internet about this MVVM pattern is really confusing and one is different from the other. Help needed !.

Thanks,
Ramprasad
Left by Ramprasad on May 28, 2009 7:17 AM

# re: Adventures in MVVM – A Testing Story
Requesting Gravatar...
Ramprasad,

I have 4 links in my "Adventues in MVVM" link at the top of my page. I think they describe, with a basic implementation, the MVVM pattern.

As far as implementation goes, the Presentation assembly from the Prism2 CAL gets you started.

If this explanation doesn't help, I am currently working on a demo for my MVVM talks next month. I will post the source code when I am finished.
Left by Brian Genisio on May 28, 2009 8:55 AM

# re: Adventures in MVVM – A Testing Story
Requesting Gravatar...
Choose - tour to 4 star Florence hotels, 4 star hotel in Rome, 4 star hotels England.Luxury cruises.Get air line ticket now.
Left by Arlen on Apr 11, 2010 9:43 AM

# re: Adventures in MVVM – A Testing Story
Requesting Gravatar...
Implementing the MVVM pattern has the biggest challenge and one of which is the View Model responding to changes in the Data Model. Usually, the View Model needs to subscribe to the Property Changed events fired by the Data Model, update its internal state, and then fire its own Property Changed events for the View.

However, using MVVM really brings out the artist in you because there's a room for experimentation and is really fun.
Left by boiler breakdown on Apr 22, 2010 1:44 PM

Your comment:
 (will show your gravatar)


Copyright © Brian Genisio's House Of Bilz | Powered by: GeeksWithBlogs.net