Home > View Post

SOA and more on why DataSets in web service interfaces are the spawn of Satan

A lot of users in the web services newsgroups ask questions about problems they're having with DataSet this and DataSet that. Usually, I'll try to solve their problem and end with some extra advice: don't return datasets from web services.

Like Scott Hanselman, I have some strong feelings about using DataSets in this way, which Scott beautifully describes in his post Returning DataSets from WebServices is the Spawn of Satan and Represents All That Is Truly Evil in the World.

Furthermore, I hear a lot of OPs (Original Posters) being told that it's fine to use DataSets if you can be sure that the client is a .NET client.

For me, this misses the point of Web Services entirely.

Apart from the fact that DataSets aren't developer-friendly or discoverable, let us look at the issue in the context of SOA (I don't want to argue about what exactly that means, we'll just assume that you're using 'services' in the WCF sense).

My employer publishes a monthly newsletter which this month had a section about SOA and agility, from which I quote:

"Analyst firm Butler Group said that SOA's create a more agile business and can help firms adapt faster to changing market conditions and future IT platforms."

Nobody knows what is around the corner, maybe ADO.NET 4.0 will drop DataSets altogether (unlikely :).

Binding your services to a single platform flies in the face of the whole foundation of services - interoperability.

Everyday, businesses are pouring vast amounts of resources into integration efforts that SOA will help to reduce.

Another key selling point of services, as with the component revolution that came before it, is reuse. If you're designing your web service with a single client in mind, you're probably not thinking about reuse.

In the short term though they're probably right, next year the client of your web service will probably be .NET.

But what about in two or five years time? Or even 10?


Josh Post By Josh Twist
7:31 AM
19 Jun 2006

» Next Post: Quick Javascript Debugging Tip
« Previous Post: SSIS Compress File Task

Comments are closed for this post.

Posted by Kim @ 19 Jun 2006 11:00 AM
The title of your post talks about *web* services specifically while your main arguments are related to SOA - Service Oriented Architecture. A web service layer may very well just be a transport mechanism for a distributed system. If the web service is just a distribution mechanism I don't see any problem using datasets. .NET 2.0 typed datatables and typed datasets together with table adapters provides in my opinion a valid approach for many systems. I think the main issue is to decide when to use what instead of being dogmatic. If you read Hanselmans' first paragraph he explicitly states that it's bad to use datasets in publicly accessible services in which I completely agree. Scott Hanselman: "(Nah, I don't really believe that, but it's a good title, no? DataSets have there place, just not as publically visible Business Objects or from publically accessible WebServices.)"

Posted by Josh @ 19 Jun 2006 2:32 PM
Hi Kim,

Thanks for your comments and I'm glad we've fired you up! For me, there is no difference between web services and the services that form part of an SOA. They are one and the same - I often use the term *web* service only to differentiate from a windows service (e.g. a background process). A *web* service doesn't have to be over HTTP, as long as it's all about SOAP and WSDL and ideally WS-I.

So, why would you use services if you're going to bind your clients to a particular platform? You might as well use enterprise services or remoting? It's just madness :)

Also, what counts as 'publically accessible'? It's public if it is available to the enterprise, and if it isn't - it's not part of an SOA.

I would seriously question the merits of an architecture that implements Data Access Layers as services alone - this is the DNA approach to service orientation and it's a different paradigm.

Finally, not using DataSets isn't expensive - it's a doddle to create types in .NET and even easier to create custom collections with the introductions of generics. You can even attribute your classes to control the wire format and this shouldn't be underestimated.

Great to hear your thoughts though and I agree that it's easy to be overly prescriptive - but when it costs nothing to make something better - is there even a choice?


© 2005 - 2022 Josh Twist - All Rights Reserved.