Why do we still use DataSets in .NET?

Question

DataSets were one of the big things in .NET 1.0 and even now when using .NET 3.5 I still find myself having to use them....especially when I have to call a stored proc which returns a dataset which I then end up having to manually transform into an object to make it easier to work with.

I've never really liked DataSets and have found them annoying to use...and as a result I've tended to keep my knowledge about them to a bare minimum (probably a very bad thing!). I also prefer to quickly transform them into an object or list of objects so I can easily manipulate them in my code.

Have DataSets passed their use by date? With the advent of O/R mappers such as NHibernate, I'm wondering if DataSets will die out or is there still a place for them? At the moment, I'm torn between whether I should set aside time to revisit DataSets and learn how to use them properly or to get behind O/R mappers 100% and just ditch DataSets altogether.

Do DataSets offer anything that technologies such as NHibernate and LINQ etc can't? If not, why then do we still use them?

Answer 1

I think I'm in the same boat: I very rarely use datasets, and I certainly don't claim to be an expert on the adapter model (I think "Fill" is the only method I have really used in production) - but they do occasionally have some uses. For example, if you need to execute some ad-hoc SQL code, can't predict the schema (and so ORM doesn't help), and don't want to mess with IDataReader etc for a simple, small set of data.

Other than that (i.e. most of the time), I prefer standard classes - either ORM or manual.

Answer 2

I think the biggest problem with datasets is they basically encouraged you to create a dbms in memory. I love the way Linq/entities cover your data needs and they rely on standard .Net collections classes and generics to work.

That said, I wouldn't write off the power of being able to dynamically read untyped data and apply relations etc. in memory, that is still very very powerful functionality depending on your situation.

Answer 3

I've never used a DataSet correctly (hooked up to an SQL Server), but it was useful for a particular need once. I found DataSet and DataView to be pretty handy and functional base classes for implementing a data/BLL tier until I could put something really thought-out in place. There's a lot of functionality back there that you should be aware of, if nothing else.

Answer 4

The most publicised use of DataSets is to create an in-memory copy of the database. I found I never used it for this, even with .NET 1.0. The disconnected model was always innappropriate in a multi-user environment.

If you ignore relational databases altogether, there are still uses for DataSets:

• If you're writing a forms application that is to load and save data into a file, you can define a typed DataSet, then load and save it using the XmlDataDocument class.

• Crystal Reports can generate reports by reading in-memory DataSets. You can create a typed DataSet just for one particular report, and use the .NET language to write complicated business logic to populate this DataSet. This saves you the from implementing the business logic using the Crystal Reports functionality (which can be a really difficult task)

• You can attach a DataGridView to a DataSet with one line of code to get a crappy user interface, which nevertheless might do the job you need. Good for things like in-house testing tools. (Not good enough to ship to a customer).

Answer 5

I find it so nice for these tables (not so much) which sure are not going to change on a long time like item lists or some kind of historical data.

Answer 6

For better or worse, the answer is simplicity. When the 2.0 Framework came out and TableAdapters were included in the process, it became ridiculously easy to get your basic CRUD type application, or even a front page showing data, rolling. Simply connect to your sever, drag your table(s) over, and the structure was in place, including foreign/primary/unique key references. Need to perform updates on this data? Use the wizard, specify your existing procedures, or let the wizard generate the adhoc/stored procedures for you.

And you're done, hook that up to a GridView and you can quickly do lots of things: resort, requery, edit multiple records while disconnected, and update in single or bulk. This kind of convenience is hard to pass up when you're working on projects that want to get done fast. Plus having things in this native "DataTable" format become convenient for XML shenanigans if that is what you need since the DataSet model uses XML under the hood for a lot of stuff.

I will admit that I have not checked out the latest versions of the ORMs out there, and I'm not sure if there is a wizard for LINQ that will do this much within a few clicks. And most people are a little slow to adapt newer technology as is, so it easy to see how it is still being used heavily.

Seeing that new Dynamic Data Service site/project is built off of LINQ to SQL or LINQ to EF, I think the tide might finally change to the newer model.

Answer 7

3 reasons to like datasets :

• For winforms they support databinding/filtering most orms don't
• Many 3rd party tools (esp reporting tools) have built in support for datatables/sets and not for plain objects..
• While debugging you can right-click on a filled table and view the contents. This is a real time-saver.
  

All in all they have a lot of functionality. I Don't like the adapters though. I usually write my own database adapters.

Answer 8

I use Typed DataSets for a really low lever orm. I know it's not half as good, but try explaining that to the big shots..
So instead of changing the world and introducing some non-microsoft oss tool (Or finally migrating from .net2.0 to 3.5, and use l2s or ef), I just use a dataset to keep my query results, and easily bind them to grids, textboxes and comboboxes where needed. I find the ability to later use something like

MyDataSet.MyDataTableRow row = // whatever
if (row.Price > 100) // do something

very useful.