Silverlight, ADO.NET Data Services, and WCF Services

I knew immediately that I wanted to use Silverlight for the user interface for my new WearMyBracket.com website. I wanted a simple, slick UI that would be straight to the point, but still leave folks a little impressed. And I felt that I had just enough UI skills to get this done.

I decided on a "flip" effect to take users through a simple order process. As the user proceeded though my order process, I would flip their canvas over for each step. This provided me an opportunity to save their progress to a database on each transition. As far as I know, there are two good ways to do this in Silverlight: an ADO.NET Data Service or a WCF Service. Either of these can run in your web application hosting your Silverlight application.

I started down the path of adding an ADO.NET Data Service to my web application. I liked the flexibiliy that this presented me. I would not have to write any custom WCF services, as any data operations I wanted to do within my Silverlight application would be possible via the REST-based data service. In addtion, my data model consisted of only a few tables, so I felt things would not be overly complex and were a good candidate for using a data service. Creating the data service is made super simple these days in Visual Studio. After I created my database schema in SQL Server, I went to my web application project, selected "Add New Item", and added an ADO.NET Entity Data Model to my project. After that model is generated from my database schema, I then added the ADO.NET Data Service. A few tweaks in code to relate the two, and I was good to go.

Back in my Silverlight project, I added a service reference to my data service, and started playing around with reading and writing to the data service. I quickly saw that this was not going to be quite as easy as I thought. Because of some of the relationships in my schema, and the way the data service needs to be tracking objects, I would have to make multiple calls to the data service from my Silverlight client in order to do some of my operations. And I also realized that maybe my scenario isn't quite right for a ADO.NET Data Service anyway. After all, my simple application would only need a couple of WCF services that could do all my work, providing simple and streamlined calls from my Silverlight app. I went back and removed my data service, added a Silverlight-enabled WCF service and was on my way. Writing the implemenation within my couple WCF services took less than an hour.

ADO.NET Data Services are flexible, in that you do not have to write any custom services for data operations. However, the I think application needs to have the neccessity for that flexibility. I didn't have that neccessity. I only had one client calling application. My data operations were few, and were not going to change. In my case, writing a couple simple WCF services was the way to go.