There’s been a lot of talk lately about MVVM (Model-View-ViewModel) in the WPF and Silverlight space. Recently, Ward Bell had an interesting post on the subject where he digs into some of the patterns he is using to support his MVVM triads. The WPF/Silverlight community is constantly droning MVVM, but almost no one goes beyond stating their use of the pattern or giving an overly general description of it. That’s why I enjoyed Ward’s post. He’s trying to get into the nitty-gritty of his UI architecture rather than just chanting “I'm using MVVM" and leaving it at that.
I’m pleased that the WPF/SL community is taking UI architecture seriously, but I think we have a long way to go. We need to dig deeper into the “how” of the MVVM and realize that a solid implementation is more that just creating a model and binding it to a view, with a dash of the Command pattern thrown in for good measure. In fact, saying you are using MVVM for WPF/Silverlight is sort of like saying you are using MVC for web development. It more or less states the general design approach you are taking to the UI architecture, but doesn’t say much about how the pattern is implemented or how individual features are represented within the context of that design. If you’ve been following the blogs on ASP.NET MVC, you’ve probably discovered that there is a lot more to it than just having Models, Views and Controllers. It is easy to use the MVC pattern very poorly and the same goes for MVVM.
Speaking of context…
When I first read the GoF book, I was baffled by its insistence that patterns were not tied to implementation. Sure, I understood that the Iterator pattern would be implemented differently in C++ than in C#, but I didn’t understand that other context-specific factors had a massive affect on the details of its implementation. This “phenomena” manifests itself in greater degrees with respect to how high-level the pattern is. A high-level pattern like MVC is a fine example of this. Consider how the implementations would differ between a WinForms and an ASP.NET implementation of this pattern. They would not resemble each other much at all. The WinForms version would likely look a lot like an Observer or Mediator while the ASP.NET version would be very similar to a Strategy. In fact the WinForms version would look so different, you might not even call it MVC anymore, though you started out with an MVC mindset. You could force the WinForms and ASP.NET implementations to look alike, but you would be creating a leaky abstraction by forcing an artificial context for your design to live in.
In the next couple of posts I am hoping to examine MVVM within the context of WPF/SL. What does the base form of it look like? What do more complex forms look like? Why is this pattern a good fit for WPF/SL? How does this pattern relate to MVP and MVC?
MVVM – A Simplistic View
If we take MVVM as a high level pattern, like MVC, then it becomes our general approach to architecting user interfaces. It means that we will have components in three of the following broad roles:
Models – These are the business-oriented components that are intended to be displayed or manipulated by the application. They might be traditional business objects rehydrated from the DB, messages from a web service or anything else that has business meaning independent of presentation.
Views – WPF/Silverlight is a view framework and is thus intended to provided these components. Their role is to display something on the screen. Nothing more, nothing less.
View Models – This is a special type of model, intended to be an abstraction of the UI. You can think of it as a logical representation of the UI. It is “connected” to the view at runtime through databinding.
My guess is that you probably feel pretty comfortable with the idea of a Model or a View. You can picture them in your mind. But when it comes to View Models, things get foggy. It means that we need to have a lot more discussion around what our View Models look like. But, we cannot just discuss them abstractly. We must look at specific scenarios and see how ordinary design patterns interplay to create a meaningful model of the UI. In a few words, here’s my general philosophy and what I hope will become clear as we proceed:
The same OOD techniques you use to build your backend systems are used to construct your View Models.
To that end, I am hoping to put together several posts on the subject. I am planning to contact several of my previous clients with the intention of gaining permission to discuss small portions of their applications; or to discuss them at a very high level. I want to show specific problems and demonstrate how we used common design patterns to build a rich View Model. It is my hope that this will begin a richer discussion on the topic within our community.
07-07-2009 10:49 PM