Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Moving From WPF to Silverlight: What are the Key Differences?

I have done one full project using WPF, and have (at least) a pretty good grasp of the main concepts, like XAML, Databinding, and MVVM. We did everything "by hand"--we did not use an MVVM framework or third-party tools. All XAML was written by hand as well (no Blend).

The new project I will start in a few weeks is pretty heavy-duty Silverlight, and I'm looking to get up to speed as quickly as possible. However most of the articles I've read on getting started with SL focus on XAML and databinding. Since my introduction to these concepts is still very fresh in my memory, I can certainly understand why these tutorials would spend a lot of time on these subjects--the learning curve can be very steep. However these are concepts that I am already familiar with, and find myself having to wade through a lot of covered ground to learn anything new and compelling.

So what I'm looking for are advice on what I need to learn and understand to go from being a journeyman WPF'er to a journeyman Silverlight'er. This can be in the form of:

  • General Advice
  • Key Differences
  • Rules of Thumb
  • Resources/Links ("A WPFer's Guide to Silverlight" would be perfect :)
  • Major Pitfalls/Things to Watch Out For

Thanks in advance for any insight.

like image 423
Phil Sandler Avatar asked Nov 05 '10 14:11

Phil Sandler


2 Answers

Rob Eisenberg (creator of Caliburn and Caliburn Micro) has a series of blog posts that talks about porting a WPF application to Silverlight. This may give you some insight into some of the framework differences.

Day 1 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/25/porting-nhprof-from-wpf-to-silverlight-day-1.aspx

Day 2 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/29/porting-nhprof-from-wpf-to-silverlight-day-2.aspx

Day 3 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/31/porting-nhprof-from-wpf-to-silverlight-day-3.aspx

Day 4 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/01/porting-nhprof-from-wpf-to-silverlight-day-4.aspx

Day 5 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-5.aspx

Day 6 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-6.aspx

Day 7 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-7.aspx

Day 8 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-8.aspx

Some other thoughts off the top of my head:

  • Binding defaults to One-Way
  • No DynamicResource
  • TabControl is fairly different
  • No ability to define implicit DataTemplates for types
  • No CoerceValue in Dependency Properties
  • Event routing is very basic
  • No built-in command structure. You have the ICommand interface, and ButtonBase controls have a Command property, though there's no class that implements the ICommand interface.
  • Missing x:Static, x:Type
  • All service calls need to be on a different thread than the UI thread. This essentially requires you to learn / implement async programming strategies. See here and here.
  • As was mentioned, it's a different framework so not all libraries are available to you. Example: there is no XmlDocument - you have to use XElement (which is arguably better, though even so)
  • The Navigation framework is totally different than WPF. Stay away from it. It will only cause you pain. ;]
  • Several of the Controls that you find in the core framework in WPF you'll find in the Silverlight Toolkit. Download it, you'll need it.
  • No built-in Triggers, though can use behaviors / actions provided in the Blend SDK (which essentially gives you the same thing)
  • If you need to interact with a database, it will have to be through services hosted somewhere, or through COM (which means Silverlight 4 OOB with Elevated Permissions).
  • I disagree with Kevin in that testing is actually fairly easy and all of the major testing frameworks and mocking frameworks support Silverlight. Where you run into issues is Code Coverage. The Microsoft Testing framework supports Code Coverage (Premium & above) or else you can use dotCover. I believe newer versions of nCover supports Silverlight though I'm not 100% certain. Use StatLight to run your Silverlight tests (regardless of testing framework) from the command line.
  • If you're not already using an IoC container pick one up. Autofac, Ninject, StructureMap, Unity, MEF. (Another bias of mine ;])

I would highly suggest looking into the available MVVM frameworks. This has cut down a significant portion of the framework code I typically have to write. The frameworks will probably only get you 80% of what you need, though that's 80% you didn't have to write yourself. I'm currently partial to Caliburn Micro, though most of the popular ones will give you what you need.

I'll add more if I think of more. Good luck in your journey!

like image 151
Joe McBride Avatar answered Oct 27 '22 02:10

Joe McBride


I've really only done Silverlight for a real app...but one of my co-workers was a big WPF guy, and so I hear some of his gripes.

  • You're going to probably need to use a WCF service, etc., for asynchronous queries to your service/business layer
  • You're using a subset of the .NET framework, so you cannot include ANY of your class libraries as a reference, only Silverlight class libraries can be included. However, you can do stuff like having a 'link to existing file' in a silverlight library that links to a file in other libraries...as long as the code still compiles with only the reduced set. This is a bit of a maintenance nightmare, but if you are doing WPF & Silverlight with some of the same code, it will probably save you from a lot of replication. Make sure to make it a link to the file and not a copy of the file, or changes in one won't change the other.
  • Unit testing your ViewModels will not be as easy. Need to Moq your service and use a Silverlight unit testing project.
  • Some of the reduced functionality is annoying for WPF veterans.
  • I think our WPF guy complained about not being able to bind stuff like a CanExecute method as easily on his commands as he was able to do in WPF. He had to call the method directly from the command or something. (I've only gotten a chance to look at MVVM a little so far as I'm now on a different project :(, so not quite sure on that one).

Hope that helps a little.

like image 28
Kevin Nelson Avatar answered Oct 27 '22 02:10

Kevin Nelson