Click here to download the code for this article.

Since the release of Silverlight 1.0 in May 2007, the platform has evolved substantially. The initial release featured a JavaScript programming model, which made it hard to build a Silverlight business application that required connecting with services and displaying data in a rich manner. Things radically changed with the introduction of Silverlight 2 and even more so with Silverlight 3. Increasingly Microsoft is positioning Silverlight as a platform that's ready to build data-driven, line-of-business applications—by including such features as extensive data-binding support, many (data) controls (e.g., DataGrid, DataForm), the Silverlight Toolkit (an open source project at www.codeplex.com/silverlight), and richer support for communicating with services.

Here I'll delve into the latter Silverlight 3 feature by comparing the options developers have for communicating with services from Silverlight. I'll do so by building a sample application called Cooking with Silverlight, a fictitious site where people can search in a recipe database and read reviews of recipes. I'll start by showing options for exchanging information with a Windows Communication Foundation (WCF) service. After that, I'll build the same application, but now using representational state transfer (REST) services. These two examples will demonstrate the differences between communicating with WCF or REST in a Silverlight app. You can download the complete code for this article by clicking the above link.

Working with Data in a Silverlight App
Silverlight uses the same Base Class Library (BCL) as the full .NET Framework, however, only a subset is available in the Silverlight platform. When browsing the assemblies, you'll quickly notice that many familiar data-related assemblies and classes are missing. Indeed, Silverlight does not contain ADO.NET and has no support for a DataSet or DataReader. In Silverlight 3, the current version at the time of writing, Silverlight has no client-side database access available, and it isn't possible to have a connection string in your Silverlight application, which would allow remote database access.

However, enterprise applications are built around data. To solve this problem, Silverlight can connect with services, on the same server on which the Silverlight app is hosted or on another server, if it complies with a few characteristics, which we'll look at in the cross-domain section of this article. Using services, we can satisfy almost every requirement for working with data in a Silverlight application. Even if we had a client-side database implementation, we'd still have the services required to use up-to-date information.

Out of the box, Silverlight can connect with several types of services, including WCF and REST. Let's first look at how the sample application was built and compare where the two technologies differ from one another.

Cooking with Silverlight
The Cooking with Silverlight website application allows users to search for recipes in a database, based on a keyword. When matching recipes are found, they're displayed in a ListBox. This ListBox has an ItemTemplate applied to it, which allows rich data visualization. The user can then select a recipe and read all the details in the detail window as well as see reviews for the selected recipe. Figure 1 shows the application.

It should be clear by now that the data lives on the server and will be accessed using services. Let's first examine how the server-side code retrieves the data from the database. The code here uses a typical n-tier approach using a combination of Entity Framework and custom-created business objects. Services will be used to expose this data. The database model is intentionally kept simple and contains only two tables, Recipe and RecipeReview. Figure 2 shows the schema.

 
To access the data, Entity Framework is used in combination with a repository for both the Recipe and the RecipeReview. The code in Figure 3 shows a part of the RecipeRepository, where first a context instance is created, followed by a query to find recipes matching the provided search term.

Data will need to travel over the wire. For that, I created my own data contract in the form of a simple data transfer object (DTO) for both the Recipe and the RecipeReview. Figure 4 shows the code for the Recipe data contract. Only types that are marked with the DataContractAttribute will be sent. Each field that should be included must be attributed with the DataMemberAttribute.

With that, the setup is ready; let's now focus on the services. To be able to talk to a service from a Silverlight application, we need to answer two questions:
• How should we design the service so it's accessible from Silverlight?
• How can the Silverlight client application connect with the service?

We'll consider both questions for the combination Silverlight/WCF and Silverlight/REST.