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

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.


"Beringer" <(E-Mail Removed)> wrote in message
news:03_Oc.13272$8G6.5120@fed1read04...
> 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
>
>

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

"Scott M." <s-(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>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.
>
>
> "Beringer" <(E-Mail Removed)> wrote in message
> news:03_Oc.13272$8G6.5120@fed1read04...
>> 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
>>
>>
>
>

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

"Beringer" <(E-Mail Removed)> wrote in message
news:03_Oc.13272$8G6.5120@fed1read04...
> 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
>
>

Hi,

"Beringer" <(E-Mail Removed)> wrote in message
news:03_Oc.13272$8G6.5120@fed1read04...
> 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.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

> 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!

>
> Jerry
>
> "Scott M." <s-(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> >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.
> >
> >
> > "Beringer" <(E-Mail Removed)> wrote in message
> > news:03_Oc.13272$8G6.5120@fed1read04...
> >> 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
> >>
> >>
> >
> >
>
>

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

"Beringer" <(E-Mail Removed)> wrote in message
news:03_Oc.13272$8G6.5120@fed1read04...
> 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
>
>

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
> "Scott M." <s-(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> >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.
> >
> >
> > "Beringer" <(E-Mail Removed)> wrote in message
> > news:03_Oc.13272$8G6.5120@fed1read04...
> >> 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
> >>
> >>
> >
> >
>
>

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

Jerry

"Scott M." <s-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>> 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!
>
>>
>> Jerry
>>
>> "Scott M." <s-(E-Mail Removed)> wrote in message
>> news:%(E-Mail Removed)...
>> >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.
>> >
>> >
>> > "Beringer" <(E-Mail Removed)> wrote in message
>> > news:03_Oc.13272$8G6.5120@fed1read04...
>> >> 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
>> >>
>> >>
>> >
>> >
>>
>>
>
>

What about a strongly typed DataSet?


"Jerry Pisk" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> To me this is the same as using ResourceManager versus using strongly
typed
> resources. Using Datasets versus strongly typed DAL.
>
> Jerry
>
> "Scott M." <s-(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >> 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!
> >
> >>
> >> Jerry
> >>
> >> "Scott M." <s-(E-Mail Removed)> wrote in message
> >> news:%(E-Mail Removed)...
> >> >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.
> >> >
> >> >
> >> > "Beringer" <(E-Mail Removed)> wrote in message
> >> > news:03_Oc.13272$8G6.5120@fed1read04...
> >> >> 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
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>