What is better practice?

[Beringer]

I'm new to the Framework and C# so I ask the following:

What is better to do when using data? Should data reside in a Dataset and
be pulled from it or should the data be placed in classes that model the
dataset and dispose of the Dataset? I suppose if changes are to be made the
Dataset would be best because then you could simply update the datastore
when done. What if the data is not changed and simply displayed?

Thanks in advance,
Eric

 

[Scott M.]

A DataSet is the way to go. It is a fully optimized class for disconnected
data that supports most database operations for CRUD and is 100% XML
friendly.

 

[Jerry Pisk]

Actually because Dataset has to work with any data structure it is the least
optimized class you will ever use (well, maybe there are other, even less
optimized generic data classes).

Updates through dataset are very simple but also the worst way to do data
updates. You're a lot better of separating your data logic into its own
layer and using database constructs such as stored procedures to handle data
retrieval and update.

Dataset is almost always the worst way to do things, it's designed to be
very simple to use, by programmers who do not have the skills to use a
database.

Jerry

 

[angus]

if you are dealing with 1 table only, use datatable instead of dataset

 

[Miha Markic [MVP C#]]

Hi,

I'm new to the Framework and C# so I ask the following:

What is better to do when using data? Should data reside in a Dataset and
be pulled from it or should the data be placed in classes that model the
dataset and dispose of the Dataset? I suppose if changes are to be made the
Dataset would be best because then you could simply update the datastore
when done.

Yeah, I would persist them in dataset.

What if the data is not changed and simply displayed?

Depends - winforms application still needs datasource (most databind enabled
controls do), while asp.net application just transforms the data into a page
(sort of) thus it doesn't need to persist the data - in this case you might
even consider using datareader.

 

[Scott M.]

Actually because Dataset has to work with any data structure it is the
least

optimized class you will ever use (well, maybe there are other, even less
optimized generic data classes).

I disagree with that statement 100%. Sure there are data stores that a
DataSet may not be the best fit for. But, by and large, if you are pulling
from a relational DB or traditional table, a DataSet is the way to go.

Updates through dataset are very simple but also the worst way to do data
updates. You're a lot better of separating your data logic into its own
layer and using database constructs such as stored procedures to handle data
retrieval and update.

DataSets do not handle updates, DataAdapters do. And, DataAdapters do
separate the data logic into thier own layer. This is why a DataAdapter
class can be found in a data provider namespace while a DataSet is found in
just the system.data namespace. DataAdapters are part of ADO.NET's Data
Access Layer and DataAdapters are not. Also, it is very simple to configure
a DataAdapter to use pre-existing stored procedures for the CRUD methods.

Dataset is almost always the worst way to do things, it's designed to be
very simple to use, by programmers who do not have the skills to use a
database.

Jerry, I don't know where you get your information, but you couldn't be more
incorrect. DataSets a highly flexible and powerful containers of
disconnected data. They allow for seamless translation to/from XML and can
be created either loosly or strongly typed. They support a DataRelations
and Constraints collection so that you can essentially have a full RDBMS in
memory and take advantage of all that has to offer.

Are DataSets the "best" thing to use. Perhaps not, but your understanding
of ADO.NET (DataAdapters, DataSets) seems very limited and based on opinion,
rather than any facts. DataSets were designed to provide a mecanism for
disconnected data storage, not as some simple data API for non-skilled
programmers - get real and get the facts!

 

[Jay B. Harlow [MVP - Outlook]]

Eric,
I would strongly recommend you read Martin Fowler's book "Patterns of
Enterprise Application Architecture" from Addison Wesley
http://martinfowler.com/books.html#eaa

As he covers various patterns for handling "data" both representing the
"data", such as Domain Model verses Table Module & Record Set. Plus
retrieving & storing that data, such as Table Data Gateway verses Data
Mapper.

He covers both the patterns and when you would apply each.

I have used both Domain Model with Data Mappers and Table Module with Table
Data Gateway in different solutions. Which I used was based on the
requirements unique to each solution.

In addition to Martin's book, Rockford Lhotka's book "Expert One-on-One
Visual Basic .NET Business Objects" from A! Press provides a pre-implemented
variation of Fowler's Domain Model & Data Mapper patterns.
http://www.lhotka.net/

Hope this helps
Jay

 

[Jay B. Harlow [MVP - Outlook]]

Jerry,

Dataset is almost always the worst way to do things, it's designed to be
very simple to use, by programmers who do not have the skills to use a
database.

I agree with Scott, I'm not sure where you get your information! As Datasets
is the .NET implementation of the Record Set pattern
http://martinfowler.com/eaaCatalog/recordSet.html. The Record Set pattern is
"An in-memory representation of tabular data". For cases where a Domain
Model Pattern http://martinfowler.com/eaaCatalog/domainModel.html is
inappropriate, I find the Record Set pattern a perfect fit! There are a
couple of other patterns in Martin's book that I have used also. See Martin
Fowler's book "Patterns of Enterprise Application Architecture" from Addison
Wesley http://martinfowler.com/books.html#eaa

Also I hope you realize Datasets, in addition to being easy for beginner
developers, have some very advanced and flexibly features, that "programmers
who do not have the skills" would never realize they are there or how to use
them.

For a complete explanation of advanced features of Datasets I would strongly
recommend you read David Sceppa's book "Microsoft ADO.NET - Core Reference"
from MS Press. As it is a good tutorial on ADO.NET as well as a good desk
reference once you know ADO.NET.

Hope this helps
Jay

 

[Jerry Pisk]

To me this is the same as using ResourceManager versus using strongly typed
resources. Using Datasets versus strongly typed DAL.

Jerry

 

[Scott M.]

What about a strongly typed DataSet?

To me this is the same as using ResourceManager versus using strongly typed
resources. Using Datasets versus strongly typed DAL.

Jerry

 

[Natty Gur]

Hi,

I agree with Jay.

As far as I concern ORM solution is the most hard to maintain but will
help a lot while updating and maintaining the system. There are two keys
to write good systems: Abstraction and decouple. Dataset seems to break
both of those ideas ... first Data model is mixed up with code to
retrieve and update DB data (yes I know it's dataset and DataAdapter but
…). Second Dataset preserve DB structure thus breaks decoupling. Every
change in DB will force changes in other system layers classes as well.
Following data mappper, on the contrary, separate both model structure
from manage code and DB structure from other application layer.
BTW, I don't remember if it mention but dataset, due to the extra data
that kept in order to enable and keep track of changing, is much less
efficient.

Natty Gur[MVP]

blog : http://weblogs.asp.net/ngur
Mobile: +972-(0)52-8888377

 

[Andy Becker]

Actually because Dataset has to work with any data structure it is the least
optimized class you will ever use (well, maybe there are other, even less
optimized generic data classes).

It is a fully optimized class for disconnected data that supports most

database operations

Opinions appear to vary widely.

How could any of us know what is optimized and what is not, except for MS?

Best Regards,

Andy

 

[Jay B. Harlow [MVP - Outlook]]

Andy,

How could any of us know what is optimized and what is not, except for MS?

I find it better to write "correct" programs then to worry about
"what is optimized". By "correct" I mean OO and use the correct tool for the
correct
job (for example: when to use a data set & when to create a domain model).
Remember
that most programs follow the 80/20 rule (link below) that is 80% of the
execution time of your program is spent in 20% of your code. I will optimize
the 20% once that 20% has been identified & proven to be a performance
problem via profiling (see CLR Profiler in my other message).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware/yetOptimization.pdf

To help decide if a data set or a domain model is going to be more
corrected, I started by reading & learning Sceppa's book on the DataSet
object model. Then I read & learned Martin's book. I identified both books
earlier in this thread. With this knowledge neatly tucked away under my
designers belt.

I attempt to learn every thing (requirements) I can about the specific
project I was working on.

Then I decide for this project what is the "best" pattern to apply, based on
the needs of this specific project. Normally if the "data" has a lot of
logic to it, I will use the Domain Model & Data Mapper Patterns. If the
"data" has little or no logic to it I will use a Table Module & Data Gateway
Patterns (aka DataSet).

Hope this helps
Jay

 

[Scott M.]

Hi,

I agree with Jay.

As far as I concern ORM solution is the most hard to maintain but will
help a lot while updating and maintaining the system. There are two keys
to write good systems: Abstraction and decouple. Dataset seems to break
both of those ideas ... first Data model is mixed up with code to
retrieve and update DB data (yes I know it's dataset and DataAdapter but
.).

Well, if you know that the CRUD methods are handled outside of the DataSet,
then stop right there. A DataSet does meet the Abstraction and decouple
concepts.

Second Dataset preserve DB structure thus breaks decoupling. Every
change in DB will force changes in other system layers classes as well.

The class remains intact, only values that the class contains will change.
This is no different than a textbox in the UI changing when the underlying
data it exposes changed in the Data Layer.

Following data mappper, on the contrary, separate both model structure
from manage code and DB structure from other application layer.
BTW, I don't remember if it mention but dataset, due to the extra data
that kept in order to enable and keep track of changing, is much less
efficient.

If there will be changes to the data, then some mechanism for keeping track
will be necessary. "Much" less efficient? Less efficient than what? Your
own class that also must keep track of data changing? If there won't be any
changes, then use a DataReader or DataTable.

 

[Daniel Billingsley]

The class remains intact, only values that the class contains will change.
This is no different than a textbox in the UI changing when the underlying
data it exposes changed in the Data Layer.

I'm assuming the other person meant just retrieving a DataSet as is from the
database and using it as the basis for the business layer. In that case,
no, it's more like a new TextBox appearing or an existing one disappearing
or changing names when the underlying data changes.

By decoupling from the DB schema the impact of a column name change, for
example, is limited to probably a couple of lines of code in one obvious
place.

If there will be changes to the data, then some mechanism for keeping track
will be necessary. "Much" less efficient? Less efficient than what? Your
own class that also must keep track of data changing? If there won't be any
changes, then use a DataReader or DataTable.

The DataSet is a pretty bloated object compared to how stripped down you
*could* make data storage. That's probably what was meant. But I agree you
some of the extra benefits that come with that size you'd have to duplicate
anyway.

The biggest disadvantage of using DataSets throughout the application layers
is that... well, they're DataSets. In my 10 years or so of using MS
development products I've already seen 3 completely different and
incompatable versions of the data access layer. No way am I building my
application around ADO.NET for that reason alone. That's obviously only my
opinion.

 

[Scott M.]

The biggest disadvantage of using DataSets throughout the application layers
is that... well, they're DataSets. In my 10 years or so of using MS
development products I've already seen 3 completely different and
incompatable versions of the data access layer. No way am I building my
application around ADO.NET for that reason alone. That's obviously only my
opinion.

The only constant in life is change. Each evolution of MS's data paradigm
has been to advance it. This is true of almost any technology.

 

[Daniel Billingsley]

The only constant in life is change. Each evolution of MS's data paradigm
has been to advance it. This is true of almost any technology.

Uh, yeah of course, and I'm not against the changes. You don't need to
convince me ADO.NET is better than RDO.

I'm simply against basing an entire application on code that is so likely to
require a rewrite.

YMMV, but as for me personally - thanks, but no. Or, as the saying goes
"Fool me once, shame on you - Fool me twice, shame on me."