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 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 2

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.

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

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 5

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 6

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.