Friday, 01 October 2010
At Convallis we've been working with .Net 4 for some time and while WCF Data Services has been around (under a different name) since .Net 3.5 Sp1 we hadn't dabbled. However, while implementing a new feature for online ConvallisCRM which required a Silverlight component I decided to experiment with Data Services to provide the Web Services needed by the Silverlight component to exchange data with.
Implementation was relatively simple, even though I decided not to use an Entity Framework object context as the data source object. While that is certainly the simplest implementation, I prefer to separate code into several tiers and since I already have a tried and tested business logic tier to provide the data to a different presenation layer I wanted to use that. So I came up with a helper class that makes relevant calls into the business tier and for all intents and purposes effectively spoofed being an object context.
Having figured out how to present the data and tested consuming it from Silverlight my next concern was error handling. In the past when designing a web service I've treated it as a messaging system and have included error details in the message payload. Unfortunately, because of the way Data Services works that doesn't appear to be an option when supplying a collection of data for instance. However, I downloaded some code from Codeplex that pointed the way and came up with an error handling system.
Having proved that I could consume the supporting data from the Silverlight component I moved on to retrieving the data that the component was to edit. Unfortunately that's were I hit a problem, the data in question is complex and and has several underlying collections of data attached to it, and so I hit an error were Data Services complained about a particular property (a collection) and not being able to support child complex types. While the class in question wasn't (in my opinion) overly complex Data Services wouldn't have it.
So it was at that point I abandoned my dabbling with Data Services, and rebuilt the code to work as normal WCF web services. Earlier in the day while still feeling my way into Data Services I started wondering if it was an appropriate technology for my problem, as opposed to web services which I've used many times before. When I hit that problem it convinced me that at least for this problem space Data Services wouldn't work.
Having said that, and abandoned implementation of it in this particular case, I am very impressed with the technology and will certainly consider using it again. I don't think I'd ever host an Entity Framework object context directly from it (unless a quick & dirty intranet app) I'd certainly look at it again if I need to supply simple data to Silverlight consumers.