Should I use the Model-View-ViewModel (MVVM) pattern in Silverlight projects?

Question

One challenge with Silverlight controls is that when properties are bound to code, they're no longer really editable in Blend. For example, if you've got a ListView that's populated from a data feed, there are no elements visible when you edit the control in Blend.

I've heard that the MVVM pattern, originated by the WPF development community, can also help with keeping Silverlight controls "blendable". I'm still wrapping my head around it, but here are some explanations:

• http://www.nikhilk.net/Silverlight-ViewModel-Pattern.aspx
• http://mark-dot-net.blogspot.com/2008/11/model-view-view-model-mvvm-in.html
• http://www.ryankeeter.com/silverlight/silverlight-mvvm-pt-1-hello-world-style/
• http://jonas.follesoe.no/YouCardRevisitedImplementingTheViewModelPattern.aspx

One potential downside is that the pattern requires additional classes, although not necessarily more code (as shown by the second link above). Thoughts?

Answer 1

I'm not sure if I can answer your question, but I have foudn the article below very valuable. Jonas Follesø is using ninject to switch out his services when in design/blend mode. Very nice!

http://jonas.follesoe.no/YouCardRevisitedImplementingDependencyInjectionInSilverlight.aspx

Answer 2

I've tried a few options and I'm settling on MVVM as the best choice for me. Blendability is an important point, and I also find the VM aspect intuitive for rigging up dynamic behaviors and procedural effects and animations (like Nikhil's Silverlight.FX). At one point I tried to avoid Blend altogether through fluent interfaces but am finding the coupling between UI and behavior too painful in the long-run. I want to design my UI in Blend and then add effects and other behaviors in code, this is proving to be the best pattern for me to follow so far.

Answer 3

I definitely think you should use the MVVM pattern for Silverlight applications - and one of the benefits of the pattern is that you can actually make your application really blendable through some simple techniques. I often refer to "blendability" as "design for designability" - that you use certain techniques to make sure your application looks great in Blend.

One of the techniques - like Torbjørn points out - is to use a dependency injection framework and supply different implementations of your external services depending on weather the code is being executed in Blend or in the Browser. So I configure my container to use a dummy data provider when the code is executing in Blend, and that way you get design time support for your list boxes, data grids etc.

The challenge is often how to set the DataContext declaratively - so I often end up using a service locator class a a "front end" to the IoC container. That way I can bind the data context to a property on the service locator.

Another technique is create some kind of ObjectDataSource control (non visual) that has two properties: Design Time DataContext and RunTime Data Context. The control does the job of detecting where is being executing, and then setting the Parent DataContext to the right object.

Answer 4

I've been using MVVM lately on a couple of different Silverlight projects and it's been working really well, I would definitely recommend it. Jonas's post is a great place to start, I've recently blogged on my MVVM experiences too and created a really simple solution to demo the main touch points.

Answer 5

I've always thought MVVM and PresntationModel http://martinfowler.com/eaaDev/PresentationModel.html are essentially the same thing. PresentationModel is a lot easier to say. I've used it succesfully in java swing, windows forms, WPF and silverlight. If you think in terms of separation of concerns a Presentation Model makes a lot of sense. You have one class whose only concern is providing a Presentation friendly Model.It really doesn't matter what technology is used to show it on the screen. It might change some implementation details but splitting the concerns apart is a good idea no matter how you show the information. Because of that separation you can easily write tests against your presentation model regardless of the view technology. So that's a plus.

Answer 6

I think many of us are waiting for the trailblazers to go ahead and create really good sample apps using MVVM in Silverlight (and WPF for that matter). There are a number of tricky areas such as the lack of ICommand in Silverlight, or the difficulty of interacting with animations starting and stopping only using data binding.

Its definitely a pattern to watch for the future though, and is worth trying out if you don't mind 'cheating' occasionally in the places where you can't quite figure it out.

Answer 7

I agree with Jonas. MVVM seems to be the model that works best for me (though John Papa thinks MVP makes more sense). I have an MSDN Article on this coming out in March that hopefully will answer the call for a good example.

BTW, I would like to see some cohesion in the MVVM Framework department. There isn't a good solution for a framework to follow yet. I like Jonas' (I think Jonas' is the FX Framework) but since its not WPF compatible it might not be the right choice for some.

Answer 8

I also agree with Jonas regarding MVVM with Silverlight. I do believe that MVP is also a good choice, but recently I have had time to try both MVP and MVVM with Silverlight and I am much happier with the results from MVVM. (Yep, I changed my mind the more I used MVVM). The VM abstracts the binding of the Model from the View (obviously) in MVVM which allows for more binding scenarios (at least claner ways to do them) than with MVP. That's just one aspect, though.

I'll be posting some examples of both MVP and MVVM with Silverlight on my site.

Answer 9

I love the ViewModel pattern and highly recommend it. I have a couple of "getting started with ViewModel" types of posts on my blog.

• ViewModel Pattern
• HelloWorld.ViewModel
• Binding Converts - VisibilityConverter
• Silverlight Airlines with a ViewModel

Answer 10

With the Feb 2009 release of Prism v2 by P&P, even better support for MVVM now available for Silverlight and WPF. See microsoft.com/compositewpf for more details.

Answer 11

i have created a example on silverlight and mvvm it is simple and short http://www.codeproject.com/KB/silverlight/Silverlightmvvm.aspx

Answer 12

I recently posted an article that discussed MVVM in details. Check out http://tinyurl.com/383odnm to learn more.

Hope this helps.

Answer 13

There's a very good Techdays 2010 video introduction to the MVVM pattern, clearly explained:

• TechDays 2010: Understanding the Model-View-ViewModel pattern

For more complicated applications that require a higher degree of automated testing it definitely makes sense, and the move away from DependencyProperties also simplifies things quite a lot.