- is up to 30x less performant than a DataReader (refer here) – the disparity in performance increases as more records are retrieved
- represents an in-memory database for the application (supports keys, relationships, validation, etc.)
- can be either strongly-typed or un-typed
- is a provider-neutral data representation
- is a dis-connected data object
- supports edits and updates as well as random access
- can be sorted, filtered
- can be very easily bound to UI controls
- has excellent integration with XML (serialisation to and from XML)
Appropriate Use CasesDataSets are often abused and thus discouraged from use. However, they can be useful in the following scenarios:
- 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
- Need for an in-memory database cache that maintains relationships amongst tables
- One-time mass loading of (master-children) data while maintaining table joins/ relationships
- Sheer convenience for prototyping/ POC
- Need to quickly (de)serialise to XML
Using DataSets as parameters to a W3C Web ServiceI’d recommend not using DataSets as web service parameters. The reasons are:
- Athough XML is universal, DataSet is still platform-specific (uses Microsoft’s DiffGrams)
- 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!
- 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.
- 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.
- Passing DataSets in web services violates WS-I Basic Profile. (reference)
- 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.