After a rocky initial few years, Silverlight's become quite the tool for creating rich internet applications, not to mention Windows Phone 7 applications. It does this by bringing the power of .NET directly into the web browser, via a plug-in. This brings one huge advantage: Silverlight, at its core, is a client application. That's right, despite being delivered over the web, Silverlight apps are built very similarly to a client application. There's no special tricks keeping track of state, requests from the user can be handled by event handlers, and all that good stuff. It's much easier to make a well- designed application because you don't have to constantly worry about reinstantiating objects. This also means you are freed from the anti-pattern design of ASP.NET. So, what's the best way to make maintainable and reusable code in Silverlight? MVVM.
The usual response to inquiries about MVVM is, "Yeah, I've heard about it," with the "What IS it?" being implied. This is partly because MVVM hasn't been well publicized, and that's partly because it hasn't really been standardized. So the simplest answer one can give to the question of "What is MVVM" is that it is a design pattern. I'm not going to diverge off onto what design patterns are, except to say that (as Captain Barbossa might say) it's more what you'd call "guidelines" than actual "rules." However, MVVM is more than a design pattern, it is really the design pattern to use in Silverlight. The reason for this is straightforward - it takes advantage of the unique relationship that Silverlight has between the Presentation Layer and the UI Layer. Silverlight may be a client app dev tool, but that doesn't make it a WinForms app dev tool. I learned this distinction. WinForms design patterns don't take advantage of that unique UI layer, but MVVM does.
MVVM describes the relationship between the Model, View, and the ViewModel. The Model and the View are pretty easy to understand. The Model is your collection of domain objects, and your business logic. The View is where you display your Model, listing domain objects, and listing their attributes. The ViewModel is the real meat of the MVVM model, and is the reason that MVVM is so necessary to a Silverlight project of any complexity. Again, this isn't official, and it isn't standardized really (again, guidelines), but at its core the ViewModel is where you hold the databinding logic that connects your View to your Model's data. Now, this is relatively unique as far as Presentation layers go. Usually, if databinding is to happen, it can't happen in the Presentation layer because the Presentation layer is too far removed from the UI. So what ends up happening is either the Presentation layer and the UI are smashed together, or the databinding happens all in real time and debugging becomes a pain. However, Silverlight's UI has built in hooks to allow for databinding to another object. This entirely changes how the UI relates to the Presentation Layer, because now the Presentation Layer can basically be anything. In fact, if you wanted, you could connect the UI directly to the Model.
So why the ViewModel? Why MVVM and not just ... MV? Because, as you can imagine, the model is meant to contain ONLY business logic. And if all you were doing, ever, was displaying the attributes of your object, then that could work, as you'd have no presentation logic. For relatively simple Silverlight apps, that could work just fine, more than likely. That raises questions though - what happens when an artist wants to work on the view? What happens when you want to test the UI? What happens if you want one view to show data from multiple domain objects?
This is where the ViewModel comes in. It provides the databinding layer for your UI to connect to. And in this databinding layer you can pull from multiple domain objects, you can sort lists, page lists, split things up and combine things together for display on the view. And the best part? You can even display dummy data for design time. That's right! Now your designer won't have to just try to build something and wonder if that's going to look right. All he has to do is connect to the ViewModel, and dummy data shows up. Now the designer has something to design against, instead of just guessing. And he doesn't need to know any of the logic, because the ViewModel takes care of all that, and if something changes, he's not totally screwed because everything is loosely coupled. Trust me, on a project of any complexity (and even simple ones!) if you bind directly to the model you will eventually regret it. And then you'll have to make a ViewModel for just one View, and then your code is inconsistent and everything is ruined forever.
Like MVC and MVP, the slowest part of design patterns like MVVM is learning them. And like MVC and MVP, once you've learned MVVM, it is significantly faster than attempting to do it the anti-pattern way. Also, trust me on this one, it's signifcantly faster than pretending that Silverlight is old WinForms tech. (That gets you nowhere, slow.) Not only are these design patterns faster to develop against than just smashing code wherever you can, but they're more modular, they're more maintainable, they're easier (and quicker) to design against, and there's generally a lot less of going back and forth over the same code trying to figure out why it breaks every time you make a change. (Again, hard lesson on that one.) This means more time focused on adding new features, and less time trying to track down hard to fathom bugs. Also, there is a nice separation of interests in the code, which lets people figure out where things are faster. Combined with templating in Silverlight, this makes application development very quick.
So MVVM works well for rapid development - once you've learned it. But it's very much worth learning. On a side note, what about rapid development with RIA? Well, that's another post. But yes, it does work with RIA.
So, hey, builtin stuff, yeah. That's most likely coming in Silverlight 5. There is a good reason that MVVM hasn't yet been built into Silverlight - it isn't that old, in all honesty, and it's still being developed, even in terms of theory. And more so, if Microsoft does include a solution, it has to be a solution that appeals to almost everyone. So it's taking a little bit to get to that point.
So in the meanwhile, there are various MVVM frameworks that have been built. The only one I've used so far is MVVM Light, developed primarily by Laurent Bugnion of Galasoft. Now he designed this framework with "Blendability" in mind. That is to say, working with designers who are using Blend is the foremost concern. He readily admits that if you are looking primarily for testability, or have other concerns, MVVM Light might not work out for you. There's also Caliburn and MVVM Foundation. Also, as mentioned earlier, MVVM isn't just Silverlight, it's also WPF. In fact, almost all the frameworks mentioned above support both Silverlight and WPF applications. So really, by learning MVVM you're getting a twofer on app skills. So hopefully, if someone out there is wondering why MVVM is useful, this has helped answer that question. Now you're wondering, hey, heavy on the "why", light on the "how", right? Well, that would quadruple this article, so I'll just post some links to others who have already written about it. Dan Wahlin, Shawn Wildermuth, and for WPF focused, Josh Smith.
Questions and comments welcome below.
Tags: software development, software design theory, design patterns, software design, a dose of theory
Exsilio Homepage | Software Development
Powered by Exsilio Solutions