LINQ + WCF + Silverlight (Part Four)
Share
In this fourth instalment we’re going to start thinking about the services layer that will ultimately link our Silverlight client to the data that drives it on the data layer. The services layer in this example is essentially a combination of a business layer, containing business objects, and a services layer, providing operations on those business objects, but the distinction isn’t necessary to illustrate the example.
Slight disclaimer: In the examples to come I hint at the possibility of another concept called the “domain layer”, an approach from Domain-Driven Design (DDD) that involves creating a domain model first, which describes the application in pure objects complete with behaviors. In this style, only after the domain model is realized do we build the database; development happens from the inside out. We introduce another step in the process where we translate a LINQ to SQL “entity” (which is really, in this terminology, a “data transfer object”) into a real domain entity and back when performing business interactions. I have left clues about ways you might approach this in the sample code but this topic is both too large to consider for this series, and I am only paying my dues in this area (and realizing some tangible benefits in the process). I may post on this topic in the future, but I am still learning.
Our first host
The service layer is one of two ASP.NET host processes that will make up our application. This is the first time in the series that we are going host running code. A practical example application that wants to feel “real world” should have application logic split between layers and servers; just imagine trying to deploy an application for the first time on multiple machines when all development has, up until that point, remained local. We still want to the integrated Visual Studio Development Server for ease of use and debugging, but the first thing we’ll do is use the project properties of our ‘ServicesLayer’ project and ensure we’re always using the same localhost port. This will ensure our WCF services don’t change configuration. So, all WCF services in this example are hosted at localhost:8080, and eventually our Silverlight host will reside on yet another port, 9090. These numbers are, of course, up to you.
Avoid dynamic ports; it will make your life a little bit easier.
Attending to the details
There is plenty of material out there on some of the configuration steps necessary to implement WCF services correctly both with Silverlight and LINQ to SQL, but here is a quick and dirty list of necessary steps you may want to check against your solution:
1. We mentioned it in the first article but it bears repeating; make sure the ‘Serialization Mode’ property in your LINQ to SQL DataContext (which you can access via the designer) is set to Unidirectional. This takes care of marking all data classes with DataMember/DataContract attributes, which are necessary for WCF in order to create proxies out of those properties.
2. Any service that Silverlight intends to communicate with must have a policy file available to ensure that Silverlight is allowed to access it. This is commonly referred to as a cross-site posting policy. Site, in this case, means port. It doesn’t matter that we’re using localhost, specifying port localhost:8080 as the services site and localhost:9090 as the Silverlight client site still constitutes a cross-site call when Silverlight tries to access the service layer. In short, make sure your ServicesLayer project contains either or both of clientaccesspolicy.xml (for Silverlight specifically) and crossdomain.xml (a standard used by Flash applications), and set their build properties so that they show up in the site’s ‘Bin’ directory as content. Here’s what my clientaccesspolicy.xml file looks like:
Remember to set the ‘Build Action’ to ‘Content’ for this file to exist in your deployment
3. Silverlight 2 Beta 2 only supports BasicHttpBinding, just in case you have found in dealing with the automated WCF service configuration on the client side of the fence (unseen hands that write your configuration markup for you) that you end up with non-functional services as Visual Studio will attempt to configure Silverlight with a custom binding (how thoughtful!). At the time of writing this article this is actually a possible bug in Silverlight 2 and you can read up on it here.
In the meantime, I suggest writing your WCF configuration markup by hand, both in web.config in the services layer, and in ServiceReferences.ClientConfig in the presentation layer. For reference, you can use this sample application’s web.config. For our example we’re going to build both a private and a public service, to get used to the concept of publishing a public-facing API for our web application (because what’s Web 2.0 without mashups), and a private service layer that we’ll use to perform data operations necessary for our application.
Article roadmap: LINQ + WCF + Silverlight
Download: Full solution
Socialized