Using classes/properties vs datasets

[Ronald S. Cook]

We're designing an app and see two basic ways to return data from the
business tier to the client:

1) Everything in DataSets
2) Fill properties of objects and manage accordingly

Any opinions as to overall approach?

Thanks.

 

[Larry Smith]

We're designing an app and see two basic ways to return data from the

business tier to the client:

1) Everything in DataSets
2) Fill properties of objects and manage accordingly

Any opinions as to overall approach?

There are pros and cons to both techniques but in the long term it's
normally much better to abstract everything away. Option 2 will likely
require more work but is almost always the better choice in my (long)
experience. You can manage a "DataSet" behind the scenes if it serves your
purpose but the interface that clients deal with should say nothing about
how the data is actually stored. The entire system should be designed so
that you can replace the "DataSet" with something else later on without
impacting your clients. This promotes clean and stable code even if you
never have to do this.

 

[Nicholas Paldino [.NET/C# MVP]]

Ronald,

Personally, I like everything in DataSets, as I don't like having to
write up all the code for my data container. I also prefer to have the
operations on the data separated from the data container itself, given that
I find it fits more with transactional processing.

However, that's not an argument against using your own objects, and
possibly placing methods to perform work on those objects. DataSets have
their own shortcomings. Particularly, for large sets of data, they can be
inefficient, and managing relations isn't as intuitive as using an object
heiarchy.

There are many more pros and cons to each side. What are your
requirements or concerns? It would probably be easier to work from those as
opposed to asking for a side-by-side comparison.

 

[Marc Gravell]

I'm an OO person myself; I like (proper) objects. Along with the other
arguments mentioned, I like (perhaps as a minority) that it divorces
the data entities from the database; OO and RDMBS are different things
and should be (IMO) represented as such. This allows me to use the
objects in an architecture-neutral, SOA fashion - (e.g. over WCF etc)
- without prejudice. It also allows me a *lot* more freedom to monkey
with the gubbins - i.e. messing around with the
TypeDescriptionProvider for a custom view etc; all of which are hard
to do with DataSets.

However, I am also a pragmatist, and I need to get the job done. If
all I am doing is returning simple data (e.g. for search results
before the "full" objects are fetched) then I will happily use a
DataTable in the same design. I'm fickle like that ;-p This allows
simple flexibility (right or wrong) in terms of which columns I bring
back - e.g. a UI search might need a lot more data than a system
search.

But Nicholas has the right of it when he asks about your requirements
and concerns. Always design around the requirements (taking best
practice into account).

Marc

 

[Tiberiu Covaci]

One more thing you should consider is the need for serializing data. With
DataSet you don't have to bother, but with you own implemtation, you have to
take this into acount. But again, as Nicholas said, you had to take into
considerations the requirements you have in your application.

Regards,
Tibi
MCT, MCPD

 

[Ronald S. Cook]

Thanks guys.. great feedback.

One more thing you should consider is the need for serializing data. With
DataSet you don't have to bother, but with you own implemtation, you have
to take this into acount. But again, as Nicholas said, you had to take
into considerations the requirements you have in your application.

Regards,
Tibi
MCT, MCPD