Adding DataSets to services... Why not?

There a lot of customers, for better or worse, who are using DataSets in their services and (I shudder as I say this) there are times when it might make sense to do so. An example might be when the developer has control of both the client and the service provider, is working in .NET, and will continue to own both ends of the connection over time. The key advantage offered by Datasets are the features such as data bindings, validation, etc.

"You'd be amazed how many people don't care or use the 20,000 extra features in a dataset - we need a lighter weight object - but until I don't have that object, I'd much rather use a strongly typed dataset, than invent my own wheel." - https://codebetter.com/blogs/sahil.malik/archive/2005/01/23/47832.aspx

One comment I heard, that me think, was that if we (Microsoft) offered more tooling around DataContracts, etc. would people continue to use DataSets in their services?

This is the notion of little 's' services vs. big 'S' services that strictly follow SOA, as you're breaking a fundamental tenet by using (strongly typed) DataSets, i.e. you're sharing implementation not just shema and messages. With WCF I have to keep reminding myself that it is more than just Web services. As WCF has consolidated several messaging technologies, not just the various Web services stacks, there are scenarios that will be not very SOA-ish.

The challenge is facilitating the use of non-SOA recommended practices such as DataSets when it is appropriate, and making it difficult for users when it is not.

 

Lhotko's blog for why you should NOT use DataSets: https://www.lhotka.net/WeBlog/ThoughtsOnPassingDataSetObjectsViaWebServices.aspx

 

Ali