Phoenix Silverlight User Group

Dave Campbell of Silverlight Cream has asked me to present at the next Phoenix Silverlight User Group meeting. If you are interested in Silverlight and live in the Phoenix-metro area, it is a great user group to join.

My presentation is titled "Using Silverlight and WCF to create a RESTful File Upload Utility". If any of those topics interest you, please come and join us! Source code will be provided on this blog in the days following the presentation. Hope to see you there!

Get the Source Code and the Slide Deck here. I will put up a proper post covering everything more fully in the coming days.

Consuming RESTful Web Services in Silverlight

Overview

This post is an extension of Rob Bagby's series on RESTful services. His 11th post details setting up a RESTful WCF service that can be consumed in Silverlight.

The key points are:

• Creating a new Service Host Factory and Interceptor to support HTTP Verb tunneling, since Silverlight supports only GET and POST verbs.
• Issuing calls from a client application to the RESTful service (including Silverlight and Fiddler)

This provides a great starting point for creating RESTful services and consuming them with Silverlight, so I decided to create a RESTful service layer around Zleek that utilizes LINQ to Entities.

Here are my take-aways from the experience:

• The WCF Rest Starter Kit makes generating RESTful services extremely easy!
• The ADO.NET generated entity classes are declared as partial so that you can easily extend them with your business logic.
• You should create a separate Data Contract version of your entities in order to facilitate serialization

I updated my Agnition.Silverlight.Utils library (see my Previous Post on Silverlight Extensions) with some utility classes for dealing with RESTful services, including request creation and serialization.

Step-By-Step

1. Download the WCF Rest Starter Kit
2. Create a blank solution and add the Microsoft.ServiceModel.Web project from the starter kit as well as the Agnition.Silverlight.Utils project into it.
3. Create a class library for your ADO.NET Entities
4. Create an Entity Data Model from your database
   
5. Create partial classes for each of your entities that you wish to write business logic or create data contracts for. Ideally this will be in a separate class library project.
6. Create a class library for your data contracts.
7. Create a Silverlight class library for data contracts. You will add all data contracts here as existing links to your other data contracts library to facilitate code sharing between your .NET 3.5 and Silverlight 2.0 libraries.
   
   
8. Optionally create Silverlight business entity classes (possibly in another library) for your Silverlight application.
9. Create a Silverlight application that you will use as your client. Ideally you should create a separate ASP.NET web application linked to the Silverlight application for ease-of-testing.

At this point, your solution structure should look similar to the following:

Now we can start fleshing out the service and client. Let's start out by creating the service. Follow Rob's Post to walk-through creating your Service Host Factory and Interceptor. After that is complete, get started making the sevice more accessible to Silverlight.

1. Remember those data contract libraries? Now it's time to flesh them out. For each entity, create a class with public properties for each piece of data you wish to expose. You can include relational properties this way as well. Here is an example:
   
2. Provide a way to project your entity class into your data contract. The easiest way (syntactically) to do this is to create an operator that will allow you to project the entity class into your data contract type while using casting syntax. The following screenshot illustrates both creating the operator and using the cast syntax to perform conversions:
   
3. Create a web service method using OperationContract and WebInvoke (or WebGet) attributes. Remember that to be truly RESTful, retrieval operations should use GET, inserts/updates should use PUT, deletes should use DELETE and appends should use POST. Response codes should be used effectively as well. Here is a GET example:
   

At this point you can either test the service using Fiddler (see Rob's post), or go ahead and create the client application.

1. Create a way to get the service URL into the Silverlight application. I like to use startup parameters. Here is how they are declared:
   
   They can only be extracted in the Application.Startup event, so I like to create a Configuration class that gives strongly-typed access to my parameters later.
   
   
2. Now we are ready to call the service and deserialize the result:
   

That's it! Easier that you thought it would be, right? Please post any comments/questions you have about this. Here is the updated Agnition.Silverlight.Utils library.