Best Practices - Adapter/dataset vrs Command/DataReader

  • Thread starter Thread starter Val C.
  • Start date Start date
V

Val C.

I'm a new VB .Net developer with a few "best practice"
questions.

Is there a best practice to identify when to use DataSets
and DataAdapters versus the Command object and the
DataReader?

Also, is there a "best practice" defined for which is the
better method to create the dataset and dataadapter?
Should you create them through code, including setting all
the binding properties for any form controls? Or should
you drag & drop them from the tool bar in the IDE and set
the properties that way?

Any suggestoins would be appreciated.

thanks
Val
 
The following excerpt is taken from
http://msdn.microsoft.com/library/d...n-us/cpguide/html/cpconadonetarchitecture.asp
Use a DataSet to do the following:
1.Remote data between tiers or from an XML Web service.
2.Interact with data dynamically such as binding to a Windows Forms control
or combining and relating data from multiple sources.
3.Cache data locally in your application.
4.Provide a hierarchical XML view of relational data and use tools like an
XSL Transformation or an XML Path Language (XPath) Query on your data. For
more information, see XML and the DataSet.
5.Perform extensive processing on data without requiring an open connection
to the data source, which frees the connection to be used by other clients.

If you do not require the functionality provided by the DataSet, you can
improve the performance of your application by using the DataReader to
return your data in a forward-only read-only fashion. Although the
DataAdapter uses the DataReader to fill the contents of a DataSet (see
Populating a DataSet from a DataAdapter), by using the DataReader you can
receive performance gains because you will save memory that would be
consumed by the DataSet, as well as saving the processing required to create
and fill the contents of the DataSet.

HTH,
Sushil.
 
Basically a datareader is for short term, quick forward only reads.
If you want to keep some data around, then use a DataSet.

My personnal preference is to do it by code using my own thin ADO.NET Layer
rather than to have code generated for me all over the place.

IMO, *the* best practice is to pick here and there what best firt your needs
(and to know why you choosed to do it this way).

In particular try to have a logical part for each part of your app so that
it's much easier to make things evolve (wether it is data access leayer, UI
generation, localization or whatever else).

Patrice
 
Back
Top