Silverlight 4 Synchronous WCF Service Calls (or “How to avoid writing a 1-tier Silverlight App”)

Silverlight is great.  Silverlight 4 is extra great.  If you know a little bit about WPF and a handful about the ViewModel Pattern, you’re in great shape.  If you’re like me, you tend to mock up your user interfaces and user interface functionality using only client-side functionality before you start to make calls back to the server-side WCF services for save/update/load operations.  This mocking strategy is great for iterating with your customer (thinking Scrum/Agile) and allows you to get a “working” user interface before you commit to implementing all the back-end business functionality. 

Well, if this is your first Silverlight application, there’s a catch.  Yah.  A big ol’ catch.  As you work from the UI back toward the service, you’re eventually going to need to start making calls to those WCF services from Silverlight.  All those calls are asynchronous.  It’s not optional either – they really have to be.  If you don’t make those calls asynchronously, the Silverlight UI locks up like a…uhhmmm…like a…uhmmm…it locks up like a blogger trying to come up with a clever simile for a completely broken and completely hung Silverlight user interface. 

So, think about the structure of an Async call in .NET: you make a call to an async method and you provide that async call with a delegate to call when it’s done.  Essentially, you tell the async method to call you back when it’s done.  That call you make to the async method is non-blocking and returns immediately.  Essentially the async method is saying “I’ll be back later.  Don’t wait up.” 

Think about what this means: any async call to a WCF service will *always* return void to its caller.

If your service calls are simple – you make one call up and you get a response back – then you’re probably not sweating this. 

If you like to keep your service calls and your business logic separated from your ViewModel and Presentation logic then you’re probably starting to sweat a little bit.  Why?  Because your user interface layer is going tend to be your integration point and, if you have to set any return values on to the UI from that service call, you’re probably going to have to provide a callback delegate to something in the user interface tier.  (Ohhh…yah…not pretty.)  Yah…that’s an n-tier violation. 

If you need to make multiple service calls in order to make a decision to populate something in your UI or ViewModel then you’re really in trouble. 

Here’s an example of what I mean. Let’s say you want to Save some Order data back to the server and that your WCF services require you to call a IsLoggedIn() to determine if you're logged in BEFORE you call the Save() method. 

Read more: Benjamin Day Consulting, Inc.: The Blog

Posted via email from Jasper-net