- Disconnnected data-container out-of-the box
- Typed datasets enhance ease-of-programming compared to "plain" datasets
- Table dataAdpaters automatically generated
- Visual designer in VS.NET to create typed datasets manually or via server explorer
- Add new data source wizard creates Typed datasets from database schema.
- Full two-way data-binding capabilities
- Built-in support to receive notifications when something changes inside.
- Search/sorting capabilities out-of-the-box (some help of DataView class)
- Work together with data adapters to retrieve and persist data.
- You can define relationships between tables (referential constraints)
- You can define constraint on columns (Uniqueness)
- Can hold many kinds of data types (.NET framework)
- The DataSet is serializable out-of-the-box (also binary )
- Has integrated XML capabilities
- Has built-in support for optimistic concurrency
- You can add custom logic in typed Dataset partial classes
- Using annotations, you can change the names of contained objects to more meaningful names without changing the underlying schema, making code easier for clients to use.
- handle NULL values out-of-the box
- Lot of third party controls support datasets
- Multiple version of a column value can exist and is available out-of-the-box (row state , GetChanges, Merge)
- With SQLdataAdapters you can load muliple tables in a dataset at once
- Everything is represented in .NET Object type. There is a lot of casting/boxing going on
- Datasets used in webservices are not ideal from interoperability standpoint
- relational API maybe too restrictive (Tables and Relations properties). Need for special methods to represent/manipulate business entities.
- DataSet is tied directly to the database model. Abstractions are more diffeiclut . you must adhere to thinking in tables and related concepts.
- Inheritance. Your typed dataset must inherit from DataSet, which precludes the use of any other base classes.
- provide the means to expose data in easy-to-access APIs without forcing every data model to fit in the relational model. You can still make a one-to-one mapping with the database but you can more easily use OO technisues to model the your problem domain.
- Advanced relationships like inheritance are possible.
- You can add any behaviour that is needed. Custom entities can contain methods to encapsulate (simple) business rules. Custom entity classes can perform simple validation tests in their property accessors to detect invalid business entity data.
- custom class can be marked as serializable
- Code can be easier to understand/maintain
- LINQ To SQL, Entity Framework are special features in future version of .NET. So MS recognizes benefits of this way of working (or is it under market pressure :)
- using custom classes makes for easier unit testing
- Programming effort can be bigger than all-dataset scenario
- you must implement a interfaces in order to provide for effective containment and data-binding capabilities
- Mapping custom collections and entities to a database can also be a complicated process that can require a significant amount of code (need for code generation/ORM tool)
- To support optimistic concurrency time stamp columns must be defined in the database and included as part of the instance data.
- Support for multiple versions of data state within an entity must be coded.
- No Searching and sorting of data out of the box. You must define your own mechanism to support searching and sorting of entities.
Sources & recommended reading
- DataSets vs. Collections, Dino Esposito, http://msdn.microsoft.com/msdnmag/issues/05/08/CuttingEdge/default.aspx
- Designing Data Tier Components and Passing Data Through Tiers , MSDN Practices&patterns, http://msdn2.microsoft.com/en-us/library/ms978496.aspx
- Dataset versus objects, Paul Stovell, http://www.paulstovell.net/2006/10/18/DataSets+versus+Objects.aspx
- Data Binding with Windows Forms 2.0: Programming Smart Client Data Applications with .NET , Brian Noyes, Microsoft .NET Development Series