You mention that you will read the data... you don't say how often.
However, in general, the dataset object was created as a disconnected
abstraction from the database. The methods on the dataset are VERY useful
for doing all sorts of tasks, from filling user interfaces, to querying on
subsets. It can be serialized across physical tiers, (which has it's
advantages on occasion but should be used carefully). It is a very good
object, that is a bit expensive to fill. If you aren't filling your
datasets every half-second, this is the way to go.
My recommendation: for all your lookup data (used to populate drop downs):
create a stored proc that returns every static lookup query under 1000
records as a series of individual SELECT statements all in one call. You
can load it up once, in a single dataset, and assign individual tables from
that to your GUI.
If you need to do a lookup against a dynamic table (list of customers) for
the sake of a dropdown, a generalized collection of rows will work. You
don't need to move the data from the DataRow that comes back from the Data
Reader. You can simply store the array of DataRow objects and pass it
around.
If you are going to make a connection, get data, fill some GUI, and not
update the database, and ever time you perform this operation, you will do
the exact same process again, always connecting, the SERIOUSLY consider
using the DataReader. It is a good bit faster than a DataSet without the
memory overhead. If you aren't going to use the capabilities of the
DataSet, it can be a waste of effort to fill it.
An excellent article to shed more light is:
http://msdn.microsoft.com/msdnmag/issues/04/06/DataPoints/default.aspx
Of course, if you want your DAL to always work in one way, and not two ways
(as I suggested), then you can create a Facade pattern object that embeds
either a DataSet or an array of DataRow objects, depending on the
constructor. You can then provide a single interface to your code, and only
allow the object itself know how the data representation in your code
actually manages the data. (That's the design tip).
I hope this helps,
--- Nick
Andrew said:
I am starting my first C# project and have a design issue which I would
appreciate some advice about. I am wondering whether to use dataset to pass
information between components or if I should implement components and
collections. I wondered what the advantages and disadvantages of both
approaches were in .NET. I am at the start of the project and would like to
make the right decision. My last project was VB and MTS and we used
recordsets as a means of passing data between tiers. It has disadvantages
but the filtering and sorting facilities were very useful.
The project will feature a rich GUI with drag and drop, a SQL server back
end, plus real time access to Bloomberg, it will be mostly readonly database
access and I am not expecting to update any database data.
