views:

371

answers:

2

Ever since .net 2.0 release this question has been discussed over a large number of times. Many of the developers are not in favour of Typed datasets and there are few who use them practically.

The goal of the question is to identify the reasons why one should use or not use Typed datasets in their applications.

In my case, I personally use them since long. I do not use them as independant-only data-access option, rather I use them as data-model which can store all SQL queries abstractly along with it.

So for me primary reasons to use Typed datasets are..

1.) A DataModel which is completely TYPED unlike tradional Datasets.

2.) Abstration of all queries from code.

What are those reasons why you may prefer or not using the Typed Datasets ? And what are the experts' advices on this topic from their experiences so far ?

+1  A: 

I tended to not use them for a few reasons:

They introduce another level of state to be managed.

The relational model of the system doesn't always directly map to the object model. Keeping them decoupled lets me optimize the relational model independently of the object model.

I'm ok with having sql queries strewn throughout the code though I may be in the minority on this. SQL is very simple, has wonderful bindings in most languages and is often programmatically constructed (I'm not talking sql-injection here, I always use bind variables where they can be used).

I think datasets were mainly intended as a way to support drag and drop data access in the forms designer. I love the table designer and the query designer but have found the extra overhead of datasets to but not worth the effort.

Arnshea
A: 

Personally, I shun datasets most of the time, simply because I like to get data out of the database and into a strongly-typed object as quickly as I can. Just for the speed I use datareaders, though that's beside the point. It's getting out of the muck of object-relational impedance that's the big part.

Chris