new to collections

[Guest]

hey all,

i was checking out time tracker on asp.net one of the starter kit projects.
i was wondering why the users datagrid gets loaded the way does. first it
pulls all the users in from a stored procedure into a dataset. next in the
code it iterates row by row instantiating a new user object and adding it to
a collection?

why would you do this when you can work directly with the dataset?
i'm very new to this just trying to understand concepts.

thanks in advance,
rodchar

 

[Karl Seguin]

I don't know the code you are talking about, and frankly going from
dataset --> custom collection seems a little on the stupid side. Its much
more logical to go from a datareader --> custom collection, which avoids the
entire dataset overhead.

From what you are saying, they are doing:

Dim ds as new dataset
dim da as new SqlDataAdapter(cmd)
da.fill(ds)

dim cc as new CustomCollection()
foreach row as DataRow in ds.tables[0].Rows
cc.add(new customItem(row))
next

in essense turning each row into a strongly-typed object and adding that to
a strongly-typed collection.

I'd change the code to be like:

SqlDataReader dr = cmd.executeReader();
dim cc as new CustomCollection()
while (dr.read())
cc.add(new customItem(dr))
end while


If you are asking about why pick a custom collection w/strongly typed object
in the first place vs a dataset, well, the answer is pretty simple:
- custom collections are more performant (datasets are bloated)
- far more importantly, custom collections return strongly-typed objects, vs
dataset which are all weakly typed, you tell me, which is less error prone:

dim customId as integer =
Convert.ToInt32(ds.tables("customers").Rows[0]("customerId"));
vs
dim customId as integer = customers(0).customerId;

The first code can throw 4 different exceptions:
- conversion could fail (maybe customId is null?),
- table named "customers" could be null,
- row 0 might be null
- field might be named something else or not exists

the 2nd code can throw 1 exception:
- customers(0) might be null. (ok, customers could be null too, but then
you have to say ds could be null in the above example).

you also get intellisense support with the latter and not the former which
is a big plus.


Now, all those things you are doing in the first case, you'll still need to
do when converting your IDataRecord or DataRow to your strongly-typed
object...but that'll be isolated into a single function, as opposed to you
having to do it (and thus changed it if something breaks) multiple places.

Karl

 

[Kevin Spencer]

why would you do this when you can work directly with the dataset?

i'm very new to this just trying to understand concepts.

Maybe they were trying to demo more than one thing in the same demo (DataSet
usage)? Who knows? You might ask the author.

One thing it is important to remember when looking at sample code: It is
sample code. It is not meant for one to use. It is meant for one to study
and understand, so that one can write one's own code intelligently.

For your part, rodchar, you are to be congratulated in that, you were able
to determine that using a DataSet to populate a Collection of objects is
probably not the best way. Even though you were not sure, you tracked down
the facts. That sort of work ethic will take you far.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

 

[Guest]

thank you all for the great replies.

Maybe they were trying to demo more than one thing in the same demo (DataSet
usage)? Who knows? You might ask the author.

One thing it is important to remember when looking at sample code: It is
sample code. It is not meant for one to use. It is meant for one to study
and understand, so that one can write one's own code intelligently.

For your part, rodchar, you are to be congratulated in that, you were able
to determine that using a DataSet to populate a Collection of objects is
probably not the best way. Even though you were not sure, you tracked down
the facts. That sort of work ethic will take you far.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

 

[Ryan Walberg, MCSD for .NET]

hey all,

i was checking out time tracker on asp.net one of the starter kit projects.
i was wondering why the users datagrid gets loaded the way does. first it
pulls all the users in from a stored procedure into a dataset. next in the
code it iterates row by row instantiating a new user object and adding it to
a collection?

why would you do this when you can work directly with the dataset?
i'm very new to this just trying to understand concepts.

The DataSet is a database concept, and they want to isolate the database
by converting the data into domain objects.

What they should be doing is using an ORM (object-relational mapping)
tool, like NHibernate, to do the mapping for them.

 

[Guest]

Regarding using a reader to populate a custom collection, if you instantiate
an object for each record that goes into the collection that doesn't slow the
application down any?

 

[Kevin Spencer]

Regarding using a reader to populate a custom collection, if you
instantiate

an object for each record that goes into the collection that doesn't slow the
application down any?

Yes. In fact, every instruction you write slows down your app. If you want a
really fast app, create an app that does nothing! ;-)

Don't worry, rodchar, I haven't missed your point. Optimization is
important. But you have to think about it a bit more deeply. For example, I
only wear RockPort shoes. They cost about $80.00 a pair, which is expensive
by most standards. However, they last about 4 times as long as shoes that
cost half as much. This means that, in the long run, I'm actually saving
money by using the more expensive shoes.

The same thing goes for writing software. Sometimes what seems to be more
expensive in terms of processing actually evens out in the end. For example,
you can use a DataSet, DataReader or a DataTable alone. If you use the
fastest (DataReader) you can only read forward, and one record at a time. If
you use a DataSet or a DataTable, you've already used a DataReader behind
the scenes to create an object, populate it, and add it to a Collection (The
Rows Collection of a DataTable, which is contained in a DataSet, both of
which are populated transparently by a DataReader). This gives you backwards
and forwards movement through the result set.

In some cases, it may be useful to populate a custom Collection, rather than
to use the generic DataTable and DataSet classes. In that case, you would
probably want to think about using a DataReader to do so, as you only need
to copy the data from each record one time.

However, as you can see, you're still populating a Collection from a
DataReader. But if you design it well, the custom Collection may require a
lot less overhead to work with in the long run than one of the built-in
"Collections," such as DataSet and DataTable (classes that implement
Collections - A DataSet, for example, has about a half-dozen Collections in
it, which you may or may not need).

As for why a given sample code did things a certain way: Many people don't
realize this, but sample code is not intended for use. It is intended to
show some functionality by example. For various reasons, such as
demonstrating how a commonly-used class like a DataSet can be used, they may
use some code that isn't particularly useful in the real world. This is one
reason that I continue to emphasize the importance of understanding your
tools.

The better you understand all the parts and pieces of a .Net app, the better
you will be at putting them together in an optimal way.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

 

[Guest]

Thanks Kevin for the great insight into this matter. I really appreciate your
time and efforts. And thanks to everyone again for your replies.
rodchar