so what you mean.. is that in an Object Class I have to Add a Property
(Field) ...while using a DataAdapter I don't need to?
Well, you only posted 2 options out of many, in terms of what you can do to
store database data in memory. The first involved using a SqlDataReader to
populate an "ArrayList of Object Instances," while the second involved using
a SqlDataAdapter to fill a DataTable or a DataSet. In fact, there are
several different ways to store database data in memory, and none of them
are strictly "the best" (overall, not just in terms of performance).
When designing software, one has to take multiple factors into account,
including performance, interoperability, extensibility, and maintainability.
Remember that performance enhances the application to a certain extent, but
the most expensive aspect of software development is the human resources
consumed in developing, extending, and maintaining the software.
A SqlDataReader is very fast, and is, in fact, used by a SqlDataAdapter in
the process of filling a DataTable or a DataSet. But there are situations
where a DataTable or a DataSet are not necessary, and situations where they
are much better in terms of interoperability, extensibility, and
maintainability. The DataTable and DataSet classes are ubiquitous in the
..Net Framework, and therefore provide much greater interoperability. They
are also serializable as XML. In addition, they can provide schema
information about the table and/or the database itself, including such
things as relationships, constraints, nullability, etc.
While an "ArrayList of Object Instances" is ubiquitous as well, it is too
non-specific to provide much in terms of interoperability, without using
Reflection. It also has none of the database properties that the DataTable
and DataSet provide. And it is not strongly-typed.
Using a SqlDataReader to populate a DataTable is more interoperable and
extensible, but does not provide the database properties I mentioned, which
are fetched by a SqlDataAdapter.
In other words, there are reasons why there are many ways to work with
database data in the .Net Framework. When considering what is best overall,
one must weigh the present and possible future requirements, and the
characteristics of the various available tools, against the performance
gains and losses, and the human resource expense that will be incurred with
each possible solution.
--
HTH,
Kevin Spencer
Microsoft MVP
Short Order Coder
http://unclechutney.blogspot.com
The devil is in the yada yada yada
