|
I always use a DataReader, never a DataAdapter or DataSet. In my opinion, DataAdapters, DataSets, and DataGrids were developed to allow Microsoft presenters to very quickly query, display, and update simple data and get an "oooh" from the crowd. They are fine for prototyping, but are not suitable for production enterprise applications. DataAdapters are very limited in what they can do and actually try to do too much -- e.g. optimistic concurrency[^].
The few times I've been lazy and used a DataAdapter in a real scenario, it bit me and I had to rework the code to use a DataReader instead.
Also, bear in mind that in ADO.net, all data access goes through a DataReader -- ExecuteScalar, ExecuteNonQuery, DataAdapter.Fill, and DataAdapter.Update all use ExecuteReader to perform the tasks.
ExecuteReader can be used to execute any SQL statement your database accepts -- queries, DML, and DDL. And, in some cases (SQL Server) you can pass a semi-colon delimited list of SQL Statements (though it doesn't report the results of non-queries the way I'd like ).
By using a DataReader you can reduce your application's memory footprint when you don't need to have all the records in memory at the same time. Or you can fill a collection of custom objects rather than a DataTable. Or you can fill a DataTable your own way and avoid the DataAdapter's overhead.
DataGrids and DataGridViews are rarely an appropriate control for displaying and editing data in real situations.
|
|
|
|