Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

DataRow Vs DataSet

Just wondered...

Will returning a DataRow to the client (in ASP.Net) be much more efficient than returning a DataSet with one row?

Similarly, is returning a DataTable preferable to returning a dataset comprising one table?

Apologies is this is obvious...

Pete
Friday, November 19, 2004

Look into using the (sql/oledb) DataReader object.  This object is more commonly used and highly efficient for servicing asp.net pages then the objects you have mentioned.


NYCCoder 
http://www.nycc.org

NYCCoder
Friday, November 19, 2004

I think the answer is that it depends. I generally pass DataSets around because in my thinking if I am just passing a DataRow or a DataTable then there is probably a better structure I could use (like say a Hashtable).

And I'm not sure what you mean by passing to the client. Is your client consuming a service you are creating, or are you just using it to populate a DataGrid or other structure?

Cory Foy (cornetdesign.com)
Saturday, November 20, 2004

"Look into using the (sql/oledb) DataReader object.  This object is more commonly used and highly efficient for servicing asp.net pages then the objects you have mentioned."

Of course it's more commonly used because it's easier. There are some massive downsides, however, such as a bogarted connection (not a problem if you immediately iterate through the reader and then dispose it, but in many cases people don't. A dataset, on the other hand, opens a firehose reader, immediately reads all of the data out, and closes the reader), as well as the fact that it is only usable in-process -- meaning when someone says that they use a DataReader, they're revealing that their data and presentation layers are in the same process. This often isn't the best choice, but rather data layers often are separated in a serviced component or a remote service.

Dennis Forbes
Saturday, November 20, 2004

To be pedantic, the DataSet does no such thing. What does that work is the DataAdapter.

Brad Wilson (dotnetguy.techieswithcats.com)
Monday, November 22, 2004

I could be wrong, but I have the impression that you have not done much development work with ASP.NET.

I use it not because it's "easier", but rather that is what it was specifically designed for w/ good ol Microsoft's blessing.  I'd say 90%+ of my data reading access within an ASP.NET application uses the datareader object.  (Conversely for .Net Windows Forms applications, I rarely use the datareader object.)

Contrary to what you think many web developers do the same.  Thankfully Microsoft addressed this need with ADO.NET as it was sorely missing from the all-in-one ADO recordset object. 

I've had good success using my data and presentation layers in the same process and is quite an acceptable, if not recommended practice.    (ASP.NET apps work under a single process themselves)

You are free to disagree with me, but I challenge you to find
your contratrian opinions in MSDN. 

NYCCoder
Tuesday, November 23, 2004

What NYCCoder siad, except that passing around IDataReaders is a performance mess waiting to happen.  It keeps DB connections open far longer than they need to be - this also has the nasty side effect of pissing off your DBA.

Of course, if you're doing quickndirty, dragndrop 2-tier coding, then a DataReader should do the trick - just watch those connections.

I'll typically pass around strongly-type Datasets if there is some stateful coding goign on, but typically pass back a DataView if I'm doing stateless work, like in ASP.Net.

Greg Hurlman
Tuesday, November 23, 2004

"# DataReaders. This approach offers the optimum performance when you need to render data as quickly as possible. You should close DataReader objects as soon as possible and make sure that client applications cannot affect the amount of time the DataReader and, hence, the database connection is held open.

The DataReader is very fast compared to a DataSet, but you should avoid passing DataReader objects between layers, because they require an open connection. "

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt12.asp

Greg Hurlman
Wednesday, November 24, 2004

"I could be wrong, but I have the impression that you have not done much development work with ASP.NET. "

Uh...okay.

Most "enterprise" development (it's a lame term, but meaning the standards at most large firms) separate data access into a separate account and process context - in .NET it's a serviced component or a web service. Your asp.net application then talks to this service passing commands or data bundles, and magically getting back results and data bundles. I really don't care if you think you're all experienced, but this is par for the course in large organization development (there are benefits and detriments, but from a security perspective it is almost always superior -- I'll guess that you either gave the ASPNET account access to your database, or you store your connection string with embedded logon information). Using a datareader in this situation is inane, and it's virtually always either XML documents, or the native version the DataSet and friends.

Dennis Forbes
Wednesday, November 24, 2004

As a sidenote the following is a very interesting article

http://msdn.microsoft.com/msdnmag/issues/04/10/CuttingEdge/default.aspx

Dennis Forbes
Wednesday, November 24, 2004

The distributed design pattern is fine for a Web Service application or a Windows Forms application and the link you provided gives credence to that.    On the other hand, it does not specifically address user-interactive ASP.NET web applications.

As for, "I'll guess that you either gave the ASPNET account access to your database, or you store your connection string with embedded logon information" is not relevant to this discussion.  It's besides the point because it could apply to either design.  Furthermore, there's application level security to consider and a single account should access the database to take advantage of connection pooling

The original poster was asking specifically about ASP.NET web applications and ADO.NET object usage.  The problem with your distributed design approach is one of latency and unnecessary "data layer" complexity with a (simple) service design pattern that is most common to HTML based web applications. 

Why should server A make a request of its own and then wait for a response from Server B before it in turn gives a response to the client?  While that was a common design for ASP/COM+ apps, it's siginificant communication overhead and unnecessary (complexity) with ASP.NET.  Instead distribute the load using a web farm. 

One last pedantic thing: in addition to your confusing DataSet with the DataAdapter, it is the DataReader object that is a "firehose" cursor; the term refers to a *forward-only* reading cursor.

NYCCoder
Thursday, November 25, 2004

Oh god this is rich stuff. Ah well, I'll humor you. I'll ignore the rest of the post as simply misinformed - I'm not saying that the KISS design is wrong (I usually advocate it), but your belief that it's the standard for ASP.NET development is simply misinformed. The thing about ASP.NET development is that in most real projects it isn't an island - the same data sources that the web app uses are used by the web services, Windows Forms app, or interfacing layers to other enterprise systems. It's really a much bigger topic than could be covered in here.

"One last pedantic thing: in addition to your confusing DataSet with the DataAdapter, it is the DataReader object that is a "firehose" cursor; the term refers to a *forward-only* reading cursor."

Firstly, what you're doing isn't pedantic - it's an Asperger-type literal interpretation and inability to contextually read (I suspect as a rather lame distraction). 99.99% of people use a specialization* (see pathetic pedantic "correction" below) of a DataAdapter to populate a DataSet, thus the two are generally bonded. Unless I'm talking to someone either mentally handicapped, with an Asperger's issue, or very new to this business, I really don't feel it's necessary to differentiate.  Let me give an extended version of the original sentence if anyone of the previous set of people happen to be reading:

OLD: "A dataset, on the other hand, opens a firehose reader, immediately reads all of the data out, and closes the reader"

NEW: "A dataset, which you populate with a specialization of a DataAdapter (though if you need to know this then I think you took the wrong offramp), is populated by having a firehose reader (of course if you're dense, let me lengthen that to "firehose cursor" reader...or even better "firehose cursor" DataReader, though of course DataReader is just an interface, so it'd have to be a class that implemented this interface as of course you can't call an empty interface! Oh god, lucky I didn't miss that) immediately read all of the data out, and then closing the reader."

There, is that better?

*- Oh, and by the way (furrows brow and prepares pocket protector in a defiant attempt at a distracting self-defense), the DataAdapter is an abstract class and thus can't be instantiated - your proposition of the same is simply unbelievably proposterous!! It's ACTUALLY a SQLDataAdapter, OleDbDataAdapter, or another specialization of DataAdapter that REALLY fills a DataSet. HA  (that is so unbelievably pathetic).

Dennis Forbes
Thursday, November 25, 2004

BTW: I'm partly replying to Brad Wilson tongue in cheek in that post.

Dennis Forbes
Thursday, November 25, 2004

Are you related to Steve by any chance?  If so, if he ever gets elected to office, please help him with the art of fillabustering.  In the meantime, take it easy and relax.  It's not worth getting red faced over.  Or is that blue?  Even a drowning man will still grasp at straws. [sigh] 

NYCCoder
Saturday, November 27, 2004

Oh yeah?  Well... well... you're dumb!  Stupidhead!

NYCCoder translated
Sunday, November 28, 2004

*  Recent Topics

*  Fog Creek Home