SqlDataReader question

[Griff]

The MSDN article:

Developing high-performance ASP.NET applications

recommends using the SqlDataReader above using DataSets.

One of the advantage of using DataSets over DataReaders is (as I understand
it) that DataSets are preferred for n-tier architecture because they can be
disconnected from the database.

I can't find any information on whether the SqlDataSet can also be
disconnected. I assume that they can, but can someone confirm that for me.

Also (I've not read up on it yet), but I assume that if some of the tiers
communicate via web-services then one has to resort to XML? If so, are
DataSets the preferred solution then?

Many thanks

Griff

 

[Sahil Malik]

Griff,

SqlDataReader is fast but is limited; it cannot do disconnected but it is
also forward only, and you will be stuck with writing concurrency mgmt from
the very scratch. Is it faster? In a single user scenario yes, in a multiple
user scenario, when database connections could be pooled, the difference
reduces.

SqlDataSet ---> There is nothing like that. DataSet is always common between
various d/bs.

WebService communication resort to XML ---> WebServices use SOAP, which are
XML. Does this mean you have to pass XML back and forth as data types from
WebMethods? Not really. Does this mean you should pass data as XML as
return/accept parameters from webservices -- Nope.

DataSets are the preferred solution for getting the data out of the d/b,
working in a disconnected mode, and persisting changes back.

- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik

 

[Kevin Spencer]

I think you may have misunderstood the article. If a DataReader was always
the best choice, there would not be a DataSet or DataTable class. These are
3 distinctly different kinds of tools, and each is best suited for the
purposes for which it was implemented.

That said, the DataReader has the least amount of overhead, and is faster.
It also has some issues which DataSet and DataTable do not, such as being
read-only, forward-only, and necessitating that a Connection remain opened
dring its entire lifetime. DataSets and DataTables are disconnected Record
Sets. The DataSet is also implicitly serializable as XML.

Also (I've not read up on it yet), but I assume that if some of the tiers
communicate via web-services then one has to resort to XML? If so, are
DataSets the preferred solution then?

Web Services are all about XML under the hood. However, they are not all
about DataSets. Web Services are simply a mechanism for making method calls,
and passing objects back and forth across a Network. So, again, there is no
"preferred solution." If you think of yourself as a builder, and these
classes and technology as tools, you should be able to see that no tool is
inherently better than any other tool, except in the context of what you're
building with it.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

 

[Mary Chipman]

Think of a DataSet/DataTable as a disconnected, client-side cache that
holds data *after* it has been fetched from the data source. The
DataSet has no knowledge of or connection to the data source
whatsoever. DataReaders and DataAdapters are what connect to the data
source, not DataSets, so DataSets are always disconnected. It's not a
question of using one over the other--you need both,
DataReaders/DataAdapters to interact with the database, and DataSets
to provide a local disconnected cache. I have never heard of a
SqlDataSet--where did you get that from? See the topic in the Help
file, "XML and the DataSet"
ms-help://MS.VSCC.2003/MS.MSDNQTR.2004APR.1033/cpguide/html/cpconXMLDataSet.htm
for more information on how to work with XML/Datasets.

HTH,

Mary

 

[W.G. Ryan eMVP]

Preferred is a big word but overall, in many distributed system, DataSets
have more applicability. You can't serialize a DataReader so it's only
useful within the context of an open and available database connection. As
such you can't remote it, return it from a web service etc. A dataset can
use a DB COnnection but it doesn't have to. Obviously to interact with a
database it needs one but it doesn't have to have one to be useful.
(Incidentally, if you look at just about any exception message that you get
from the db, you'll notice in the stack trace that a data reader is
mentioned. This is because, under the covers, readers are used to
facilitate just about anything you do with the db - they are even used when
you fill a dataset with a DataAdapter.)

In the context of Enterprise solutions though, it's often useful to think in
terms of SOA. What service are you going to provide? You can have for
instance a facade that gets called from the client. The facade in turn
invokes some method to get the data it needs and it returns it. By doing
things this was, you can change your back end around quite a bit and the
client would never know the difference. SOA in turn allows you to use a
DataReader, MSMQ, Web Service or whatever else to get the client the data
you need so it affords quite a bit of flexibility

Take a look at the Microsoft Data Access Application Block - and some of the
examples there, it should be a good starting point in helping you to
understand how to use each.