One of the things that I had to make a decision about early on in my pet project was how I was going to transfer data back and forth from the web service to the client.

My initial thought was that whenever I was performing a CREATE operation I would pass all the fields of the item being created as parameters to the web service function. Then when I was retrieving data I would return things as instances of specialized data classes. In the cases where I wanted to get a list of items I would resort to sending a dataset back and forth. In general this worked out OK.

The initial datasets I was working with were untyped, generic datasets. Very quickly I learned how to create the typed datasets and since then I've never ever made use of a generic dataset. I think of the generic dataset class as a base class, not something that I should be using directly. The reason for this is the fact that typed datasets are strongly typed and all access to fields are checked at compile time - something that saves me debugging time. Besides the wonderful Intellisense feature in Visual Studio eliminates the need for me to remember what the fields are called (my memory is so bad when it comes to names!!!).

But what more happens when you use typed datasets...one of the added benefits is that the XML being transmitted in the web service actually becomes more readable. And in the case where the web service client is written in .NET once you register the web service, the typed dataset definition magically becomes available to the client and it too can use it directly. Of course the same is true for any classes defined as parameters or return values in web services, but the good thing is that typed datasets always get the fields mapped accross the wire, while there are certain data types that don't map easily in custom made classes.

So what I did was gradually I removed most of the specialized data classes from my code and replaced them with typed datasets. The Create, Update, Delete functions disappeared and were replaced by a generic Update functions that could do all three using a dataset.

But what were some of the issues I faced when I did this:

  • Clients not written in .net had to learn how to work with the XML format expected by datasets
  • There was an additional overhead when passing data back and forth (this was bit of a concern due to the fact that the system is used over GPRS - which has a latency of 1.5 seconds per call)

But these issues were overweighed by the simplicity, ease of use and clean architecture that resulted as a result of this decision.