My short answer is yes, however some context must be provided in order to make the answer comprehensible. Typed DataSets emerged as part of the Microsoft’s massive efforts to make the “Smart Client” architecture the de-facto standard.

This architecture mostly relayed on two concepts: off-line capabilities and rich user experiences. In that time Microsoft was launching the Framework 1.1, so the obvious implementation strategy was exposing Typed DataSets to Windows Forms applications through XML Web Services.

The Smart Client architecture became very popular and Typed DataSets were the favourite way to solve occasionally connected scenarios.  In fact, the Autonomous Application architecture became an architecture style. This architecture distilled the following behaviours:

  • Data is completely controlled and denied to the outside world.
  • Communication is based on messages.
  • Data is a snapshot rather than the real thing.

I would say Software Developers prefer Linq + Entity Framework -EF- nowadays, so in practical terms I agree typed DataSets are dead, but the basic ideas are now part of the latest data access technologies, remember that the DbContext’s caching mechanism is the implementation of the unit of work pattern; that mechanism heavily resembles the “snapshots” proposed by the Autonomous Application architecture, so the Typed DataSets really did not die.

I remember the days when it was necessary to write the Select command to add it to a SqlDataAdapter class instance in order to fill a typed or weakly typed DataSets; now we can code first a model and let the object mapping and scaffolding happen, without using them. Don’t take me wrong, this means that we have now more options (in different abstraction levels) to chose from, depending on the needs. In fact there are plenty scenarios (here a sample) where DataSets and DataTables are very useful.

I would like to mention that the lack of interest on TypedDatasets does not mean that the entire ADO.Net stack (DataSet, DataView, DataTable, DataAdapter, DbCommand and DataReader) is falling too. In fact, EF is built on top of ADO.Net; if you use EF you’re already using this stack, you can find in the Entity Framework source (in CodePlex) classes like the EntityDataReader which uses an ADO.Net object. In the following sample code from the Entity Framework a DataReader is used.

public override bool Read()
return _storeDataReader.Read();


Javier Andrés Cáceres Alvis

Microsoft Most Valuable Professional – MVP
Intel Black Belt Software Developer