Are MVVM Patterns in WPF and Silverlight identical?

Question

I really appreciate the question (and answers) we already have in “List of WPF functionalities that aren’t in Silverlight 3.” My allegedly new question narrows down the differences between WPF and Silverlight into the context of MVVM. Based on a Shawn Wildermuth MVVM sample project I downloaded from MSDN, I do see that, as of Silverlight 2, “Element Binding isn’t supported yet…” But this surely is just one detail and is this still the case? Is there a summary of MVVM-centered differences between WPF and Silverlight? Can we build our apps to move with more ease between the two technologies?

Update: Silverlight requires that calls to external resources be asynchronous whereas in WPF it can be synchronous or asynchronous. This requirement in Silverlight is due to the Web-based nature of the technology.

Answer 1

The pattern is identical, but the implementation may differ. Silverlight is missing some crucial pieces such as commands that mean you may need to put a little more effort into achieving an MVVM solution. However, at the end of the day, you'll still end up with M's, V's, and VM's.

HTH, Kent

Answer 2

Element binding is now available in Silverlight 3, along with a couple different options for implementing actions. There are behaviors, which are pretty easy to code, as well as commands if you use a framework like Prism (from the Microsoft Patterns and Practices team, not included in Silverlight by default). There's also the Visual State Manager, which is in Silverlight only right now, that handles a lot of the routine kinds of animations you might want if what you're doing is state-based.

Building apps to move between the two technologies is a different matter though. There are a number of XAML elements that are not supported on Silverlight (and some SL stuff not in WPF) and the underlying runtime is specifically kept small to facilitate web deployment, so there are and will continue to be a number of things missing. I don't think we'll see completely cross platform applications (code once, compile into both WPF and Silverlight without changes) in the near future and I think that in anything but the most trivial of examples the code revisions are going to be significant.

This doesn't mean that you can't apply MVVM to both or that the skillsets don't apply across both. If you are familiar with one, you're certainly 80% of the way there on the other immediately (that 20% can be tough though!) and understanding the pattern (I use databinding to get synchronization code out of the view and into the view model, I use commands/triggers/behaviors to remove actions from event handlers in the code behind of the view, etc.) means that you know what to do, even if how you do it is going to be a little different. From that perspective, I think we're about as close as we're going to get to achieving parity at a pattern level.

As for a summary of the MVVM pattern implementation differences between Silverlight and WPF, I haven't found one. Sounds like a good topic for a blog post from someone though...

Answer 3

The MVVM pattern in Silverlight is completely different with WPF. That's due to the lacking of commanding framework and routed event in Silverlight.

Microsoft standardized the use of DelegateCommand and CommandReference in the recently released WPF MVVM Toolkit. However, there's no such thing existed in Silverlight as it doesn't include complete command implementation.

My company recently developed a comprehensive MVVM Framework that brings WPF-style MVVM into Silverlight, which includes DelegateCommand, CommandReference, RoutedCommand and RoutedEvent. With our framework, it's possible for you to create MVVM application in Silverlight and migrate it to WPF without major codes rewriting. Check my blog post http://tinyurl.com/383odnm for more details.

Hope this helps.