DataReader vs DataSet

  • Thread starter Thread starter Morgan
  • Start date Start date
M

Morgan

Thanks for any insight in advance.

Using the MS Building Blocks for Data Access in an ASP.Net app, I have a
couple of questions.

In theory, via the browser, a user will never be working with more than a
single record at any given time, so why use DataSets for DB access? I am
accessing the data via a middle-tier and passing objects to the web app,
thus losing all benefit of using the DataSet.

Given this theory, I am considering shifting to the SQLDataReader for
read-only data access, to reduce the overhead of having to process DataSets
in the middle-tier. Are there any reasons why this would not work or be a
viable solution?

For Add/Update/Delete operations, I have seperate methods that get called in
the middle-tier using Stored Procedures.

Thanks,

Morgan
 
I don't recommend you to transport Datareaders between the
layers in you applications, because the DataReader must
have an open connection. Instead of a DataSet I think you
should use the DataReader in your Data Access layer and
fill entity objects and pass this entity object between
the layers. Enityt objects are loose-coupled and will
increase performance if you use it right. I can recommend
you too look at the PetShop example.
http://msdn.microsoft.com/architecture/default.aspx?
pull=/library/en-us/dnbda/html/PetShop3x.asp. I like the
version 2.0 better then the version 3.0 of the Petshop.
The new architecture in the version 3.0 could be
implemented in a better way, but it's my opinion.


/Fredrik Normén NSQUARED
 
Thanks Frerik.

That's exactly how I'm doing it now with DataSets.


I don't recommend you to transport Datareaders between the
layers in you applications, because the DataReader must
have an open connection. Instead of a DataSet I think you
should use the DataReader in your Data Access layer and
fill entity objects and pass this entity object between
the layers. Enityt objects are loose-coupled and will
increase performance if you use it right. I can recommend
you too look at the PetShop example.
http://msdn.microsoft.com/architecture/default.aspx?
pull=/library/en-us/dnbda/html/PetShop3x.asp. I like the
version 2.0 better then the version 3.0 of the Petshop.
The new architecture in the version 3.0 could be
implemented in a better way, but it's my opinion.


/Fredrik Normén NSQUARED
 
Please explain this more, I'm a newbie and just started getting into the
..Net stuff yesterday.

I tried installing the PetShop code but it kept throwing errors during the
installation process so I could not see the code samples. What do you mean
by entity objects? I agree passing the DataReader between layers seems
ineffiecient because you can't close your connection until you are done
using it. Apparently there is no such thing as disconnected recordsets
anymore and DataSets seem too bulky and resource heavy for this purpose.
From your comment, it seems that you somehow fill these entity objects
before passing them to the business layer, how is this accomplished? It
seems like you would have to loop through your records twice, once when
filling the entity objects and again to display the records (or whatever you
were going to do with the DataReader). Is the overhead worth it or am I
missing something?

Also, as a side observation. Once a DataReader is closed, it can't be
re-opened can it? So, how should I return output parameters and queries
from the same time stored procedure? If the entity object method works, it
will solve this issue as well.

Thanks in advance.

Dan


I don't recommend you to transport Datareaders between the
layers in you applications, because the DataReader must
have an open connection. Instead of a DataSet I think you
should use the DataReader in your Data Access layer and
fill entity objects and pass this entity object between
the layers. Enityt objects are loose-coupled and will
increase performance if you use it right. I can recommend
you too look at the PetShop example.
http://msdn.microsoft.com/architecture/default.aspx?
pull=/library/en-us/dnbda/html/PetShop3x.asp. I like the
version 2.0 better then the version 3.0 of the Petshop.
The new architecture in the version 3.0 could be
implemented in a better way, but it's my opinion.


/Fredrik Normén NSQUARED
 
Please explain this more, I'm a newbie and just started getting into this
..Net stuff yesterday.

I tried installing the PetShop code but it kept throwing errors during the
installation process so I could not see the code samples. What do you mean
by entity objects? I agree passing the DataReader between layers seems
inefficient because you can't close your connection until you are done using
it. Apparently there is no such thing as disconnected recordsets anymore
and DataSets seem too bulky and resource heavy for this purpose. From your
comment, it seems that you somehow fill these entity objects before passing
them to the business layer, how is this accomplished? It seems like you
would have to loop through your records twice, once when filling the entity
objects and again to display the records (or whatever you were going to do
with the DataReader). Is the overhead worth it or am I missing something?

Also, as a side observation. Once a DataReader is closed, it can't be
re-opened can it? So, how should I return output parameters and query
results the same stored procedure? If the entity object method works, it
will solve this issue as well.

Thanks in advance.

Dan


I don't recommend you to transport Datareaders between the
layers in you applications, because the DataReader must
have an open connection. Instead of a DataSet I think you
should use the DataReader in your Data Access layer and
fill entity objects and pass this entity object between
the layers. Enityt objects are loose-coupled and will
increase performance if you use it right. I can recommend
you too look at the PetShop example.
http://msdn.microsoft.com/architecture/default.aspx?
pull=/library/en-us/dnbda/html/PetShop3x.asp. I like the
version 2.0 better then the version 3.0 of the Petshop.
The new architecture in the version 3.0 could be
implemented in a better way, but it's my opinion.


/Fredrik Normén NSQUARED
 
Morgan,

Passing a DataReader undermines your three tier design. If you are worried
about performance, you can pass an object array, but you lose strong typing.
If you roll your own container to pass between layers, you can hurt your
performance if you aren't careful.

Kathleen
 
Back
Top