DataSets, DataAdapters and bad design

  • Thread starter Thread starter Andrew
  • Start date Start date
A

Andrew

Does anyone else think the whole design of ADO.NET is a piece of ****?
The DataSet is basically a mini, in-memory database. Heavy, tough to
move data in and out of the database (@@Identity issues?). I've been
developing desktop, web and n-tier applications for over 10 years and
have never had a need for anything like it.

Or do I just not get it? What am I missing? It seems to me all you
need is a DataReader, a Command object, and a well designed data
access layer. What do you need a DataSet/DataAdapter for?
 
Andrew said:
Does anyone else think the whole design of ADO.NET is a piece of ****?
The DataSet is basically a mini, in-memory database. Heavy, tough to
move data in and out of the database (@@Identity issues?). I've been
developing desktop, web and n-tier applications for over 10 years and
have never had a need for anything like it.
Click to expand...


Short answer;
Actually I find it very good.
Identity issue is handled just fine.
So, where do you store data that your user manipulates?
With datasets: load data using adapters - manipulate it as you wish - store
it at the end.
 
It depends your needs. For results pagination you could choose to cache a
DataTable to have a database hit only for the first query and then construct
other pages using cached data... For a disconnected Windows app, you could
probably have a local DataSet persisted to disk, mark some items for
synchronization and then synchronize them in connected mode...

In the whole framework it's likely you'll find numerous things you don't
need...

Patrice
 
I respectfully disagree. You don't necessarily need DataSets and the
adapters, you are correct, depending on your app. However, they can do quite
a bit for you. Accessing Data from a Web service and being able to write
DataAccess code that works without modification on a PDA, Desktop, WEb
application and web service is huge.

Readers need open connections and you can only move in one direction with
them. You can certianly write tons of code to impersonate things like
Idendity columns, and their seeds and data relations etc, but ADO.NET gives
you a very Clean and easy way to do this.

How about things like a Dataview? Making a trip back to the Database each
time you need a filter changed isn't efficient.

Also, the ability to have your app work in a completely de-coupled mode is
huge. If my connection fails for instance, my app then writes the DataSets
to XML and whenver it can connect later on, submit those changes.

In an increasinly wireless world, this is not just a cool feature, it allows
you to do things that would otherwise take zillions of lines of code to
accomplish.

What issues with Identity are you having? This subject is so common, and I
have yet to see of an instance where it was a problem when the people know
how to use it. With all due respect, I think some of your frustration may
be due to an incomplete understanding of how to use it.

Just my two cents.
 
I found it very good. no complaints. identity issues handled very well. it's
very free formative in use. retrieve anything, update anything.

Rajesh Patel
 
Back
Top