DataSet vs. Collection of Objects

[Brad]

I have an application that is highly CRUD-centric for data management with
some more sophisticated reporting behavior. I'm trying to decide between
using strongly typed datasets vs. collections of objects. I want to
decouple the business logic and UI from the persistent storage so that the
impact on changing the database doesn't ripple upwards. At first blush it
appears that the dataset approach forces some coupling. Would somebody
please comment on this.

Thanks in advance.

Brad

 

[sloan]

Its only coupled if you use the magic/built in / voo doo populaters.

YOu can use either strong datasets or business objects as the glue between
layers.


http://sholliday.spaces.live.com/blog/

6/5/2006
Custom Objects and Tiered Development II // 2.0


I have dataset code there also, ( in the 1.1 version from may ) ....

but it shows how to use/populate datasets without the voodoo.

And a reference to read from start to finish, aka, very informative for a
bird's eye view:
*
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp


REad the section
Deploying Business Entities

very carefully

 

[RobinS]

This is the methodology that I use. It takes a little bit more trouble, but
it seems very clean to me. If I need to change my data source, I can
change my data layer. If my field names change, I can change the locations
where the business object fields are retrieved from and stored to the
dataset, and not have to change any of my UI unless I want to.

I'm assuming you've checked out Rocky Lhotka's book. For a more pragmatic
and applied approach, Deborah Kurata has just come out with a new book
called "Doing Objects in VB2005" that gives an example of how to create a
3-layer application. I know it's in VB, but you could figure it out. It has
some neat stuff about how to use code snippets and stuff like that, too.

Robin S.

 

[pfc_sadr]

datasets are crap

datareaders rock; but connections suck

in good old classic ADO you could decouple the relationship between
the data layer and objects

ADO.net is 'unnecessary change'

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

datasets are crap

Then don't use them. I don't.

datareaders rock; but connections suck

Hm... I don't really see what you could use a an alternative to a
database connection?

If you mean that having to keep a connection open until you have used
all data, you don't have to. Just read the data, close the connection
and then use the data.

in good old classic ADO you could decouple the relationship between
the data layer and objects

....Effectively turning the Recordset object into something that more
resembles a DataTable object than a DataReader object.

ADO.net is 'unnecessary change'

Maybe not necessary, but I think that it's a good change. I really like
the datareader.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I have an application that is highly CRUD-centric for data management with
some more sophisticated reporting behavior. I'm trying to decide between
using strongly typed datasets vs. collections of objects. I want to
decouple the business logic and UI from the persistent storage so that the
impact on changing the database doesn't ripple upwards. At first blush it
appears that the dataset approach forces some coupling. Would somebody
please comment on this.

There are quite a bit of personal taste in that choice.

From a very purist point of view I think that the collection
of objects is more decoupled from the data origin than a
typed dataset. And it comes with less out of the box functionality
that you may not want to expose.

For a large project I would definitely prefer the collection
of objects.

For a small project I may like the out of the box capability
of the dataset.

But it is close to be question like how many places to indent
or how to place the curly brackets.

I like what I have described, but if you (or more precisely: the
place where you work) prefer the dataset, then that is it.

Arne