E
Elliot Rodriguez
As I continue to read more about the benefits of database querying using
ADO.NET, I am having a more difficult time distinguishing what the best
approach to data retrieval is anymore.
When creating datasets in the Visual Studio.NET designer, Command objects
(Update, Insert, Delete) are automatically generated for you based off your
SelectCommand value. You then get the benefits of strong typing, which from
what I've seen so far are helpful in a limited sense - perhaps I've not seen
enough of it to give an accurate assessment, but the main benefit seems only
to be within codebehind (read: Intellisense) in VS.NET... but I digress.
It seems that creating datasets in the designer is of benefit for simple
queries (at least thats what the examples that I've read have led me to
believe). If you want to query using stored procedures or views, the benefit
of the Command objects are lost. But you have far greater flexibility in
your queries.
Now, lets assume that I want the Command object benefits, and instead
perform queries on datasets (versus using stored procs), using DataRelation,
DataTable, and DataView objects. I just do all my joins on the in memory
tables and boom - same results as a stored procedure. Keep these tables in
cache, and at the end of the day (or whenever is appropriate), commit
changes to the datasource.
Which is the "preferred" method? It seems very unwieldy, especially for the
enterprise, if you have tables with several million rows (I imagine the
tranasctional management nightmare scenario), put them in cache, let users
make modifications, then validate all the changes prior to updating the
datasource. Is it possible to get the benefits of the Command objects while
still using stored procs?
From a slightly confused reader
Thanks
ADO.NET, I am having a more difficult time distinguishing what the best
approach to data retrieval is anymore.
When creating datasets in the Visual Studio.NET designer, Command objects
(Update, Insert, Delete) are automatically generated for you based off your
SelectCommand value. You then get the benefits of strong typing, which from
what I've seen so far are helpful in a limited sense - perhaps I've not seen
enough of it to give an accurate assessment, but the main benefit seems only
to be within codebehind (read: Intellisense) in VS.NET... but I digress.
It seems that creating datasets in the designer is of benefit for simple
queries (at least thats what the examples that I've read have led me to
believe). If you want to query using stored procedures or views, the benefit
of the Command objects are lost. But you have far greater flexibility in
your queries.
Now, lets assume that I want the Command object benefits, and instead
perform queries on datasets (versus using stored procs), using DataRelation,
DataTable, and DataView objects. I just do all my joins on the in memory
tables and boom - same results as a stored procedure. Keep these tables in
cache, and at the end of the day (or whenever is appropriate), commit
changes to the datasource.
Which is the "preferred" method? It seems very unwieldy, especially for the
enterprise, if you have tables with several million rows (I imagine the
tranasctional management nightmare scenario), put them in cache, let users
make modifications, then validate all the changes prior to updating the
datasource. Is it possible to get the benefits of the Command objects while
still using stored procs?
From a slightly confused reader
Thanks