Use and abuse of the .NET DataSet

Here are some facts about the DataSet that ones needs to be aware of.
A DataSet:

1. is up to 30x less performant than a DataReader (refer here) – the disparity in performance increases as more records are retrieved
2. represents an in-memory database for the application (supports keys, relationships, validation, etc.)
3. can be either strongly-typed or un-typed
4. is a provider-neutral data representation
5. is a dis-connected data object
6. supports edits and updates as well as random access
7. can be sorted, filtered
8. can be very easily bound to UI controls
9. has excellent integration with XML (serialisation to and from XML)

Appropriate Use Cases

DataSets are often abused and thus discouraged from use. However, they can be useful in the following scenarios:

1. Need for a dis-connected data object that is to be batch-edited, separately updated and subsequently synchronised with the database. Although ideal for OCC or desktop client, this is also possible for a web application with a session-based DataSet
2. Need for an in-memory database cache that maintains relationships amongst tables
3. One-time mass loading of (master-children) data while maintaining table joins/ relationships
4. Sheer convenience for prototyping/ POC
5. Need to quickly (de)serialise to XML

However, apart from the above, I'll recommend not abusing it.

Using DataSets as parameters to a W3C Web Service

I’d recommend not using DataSets as web service parameters. The reasons are:

1. Athough XML is universal, DataSet is still platform-specific (uses Microsoft’s DiffGrams)
2. DataSet may, arguably, be too flexible – it fundamentally means that the web service parameter is of the XML type <any> in which the schema is only made available at run-time as part of the XML payload. This allows the provider to make changes to the structure without modifying the WSDL contract. Consumers may only know of a change if it breaks existing functionality!
3. The domain-driven design (exposing custom entities) may be more appropriate. This is especially since ADO.NET Entity Framework appears to be the way to go in the future.
4. Principles like Separation of Concerns and Encapsulation are violated. Since (more often than not) DataSets are direct representations of the database structure, exposing DataSets removes the abstraction from the database.
5. Passing DataSets in web services violates WS-I Basic Profile. (reference)
6. Even if it works, non-.NET toolkits will not be able to infer the DataSet schema to generate any useful OO classes/ structures. Such consumers will then have to fall-back on primitive XML parsing.

The following articles extensively examines the web service interoperability between .NET and Java platforms.

• MSDN article
• Oracle article