One of the comments I got on my last post on view/view model hookup options was the following:
I've been a mvvm fan but actually when I see all the hoops to jump through I wonder at times how effective this is
So I wanted to take a moment to list what I thought compelled me to adopt the ViewModel pattern of client application development (so much so, that I now feel odd writing Silverlight and sometimes even Ajax apps in any other way). Some will be obvious benefits, especially to those already using MVVM in their everyday development, but I want to throw in a couple that are farther out exploratory ideas that I am thinking about. I'd also love to pursue what it means to make view model more mainstream, so if you've got ideas on this topic of "Why ViewModel", I'd love to hear.
The often cited benefit is increased testability of additional code within the application, and I'll get to that, but I think there are some other benefits that are more applicable, considering not everyone practices the rigor of the level of testing we're talking about here. Essentially, testability is not a justification for the ViewModel pattern on its own.
Making the Conceptual Model of the Application Concrete
The core of the application is comprised of the data it presents, the operations it enables, and the logic/behavior that cause it to move from one state to another.
The ViewModel pattern (as well as the complementary MVC pattern) help encapsulate that core of the application into a concrete form, separated from the user interface and user experience parts of the application, which aids in understanding and maintainability of the code over the long term. In the absense of such separation, all of the state and behavior take on the form of spaghetti, distributed into UI controls, event handlers and code-behind members.
This was the primary reason why view model generally defines the structure and approach I like to take with my application development.
My last post discussed how the view and view model are associated with one another. And in the diagram above, I tried to convey how the key XAML constructs: bindings, actions and triggers allow hooking in a late-bound, decoupled manner, to data, operations and notifications implemented as properties, methods and events on the view model.
The separation leads to a number of second order benefits, one of which is testability. The core of the application can be tested through a unit test, which effectively simulates a view.
Facilitating Designer/Developer Workflow
The view model class serves as a nice contract between the designer and developer roles within a project. As long as the designer and developer have a general agreement on what is the shape of the data, the operations and notifications, the designer can focus on polishing and iterating, as well as evolving/changing the UI design and UX, and the developer can focus on implementing and optimizing the underlying behavior, how data is fetched, stored and managed on the client, the services that are to be requested, when, and how often etc. etc. Furthermore, these design and development can happen in parallel.
Jumpstarting Development
OK, this is a very developer centric view. I often find I get bogged down designing the UI, and focusing on little details too early. Instead, with the view model pattern, I can focus on wring the logic of the app and simply not care about the UI. Throw in RIA Services, and I can build the server portion of my app as well, and have the view model call into it, and get a generally working end-to-end app before writing any XAML.
Updated: A Pattern that Scales, and Lets You Scale
Do read the first comment below, from Darren Oster. It captures an essential element of why, which I'll summarize - as a pattern it applies to small projects and works well with complementary patterns like dependency injection, etc. when working on larger projects. And even more importantly, it lets you scale better, by allowing you to focus on one portion of your application at a time.
As mentioned, I also want to briefly mention some early ideas I have in the back of mind, for how view models help address some more fundamental problems, or can improve the application development workflow, should the ViewModel pattern indeed become mainstream over time.
Making Async Simpler
Async programming is hard, and the natural desire is to simply avoid asynchronous work and instead do things synchronously. This has the problem of getting in the way of responsive UI. What if all application-specific work could be done on a background thread where it was free to block, while freeing up the UI to process input, animate, and paint?
To add to that, there is an increasing desire to do more work concurrently to leverage many-core hardware. But that just made the async problem even harder. What if multiple bits of interesting application work can be moved to multiple background threads.
Essentially, what I'm getting at is what if view models were run in the background? They're already decoupled from the view, and so they shouldn't need to touch any UI objects. The interface between the view and view model (as shown in the diagram above) - the bindings, actions and triggers could take care of marshalling across threads. The nice thing is they're all system/platform code and so most app developers don't need to care about the details. Instead they get to focus on their application logic housed within view models.
Integrating Prototyping into Application Development
Sketchflow is a great tool to quickly prototype the screens of the application. It facilitates iteration, experimentation, and collecting feedback by designers, developers in conjunction with actual customers/users of the application.
The output of the sketchflow and prototyping effort is a blue print for the application's user interface. But it can be more. What if it is also effectively constructing the contract exposed by the view model? What if the output is an interface that the developer of the view model must implement, and that the designer can assume and design the actual view around?