Scott on Writing

Feedback

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/27/2005 8:58 PM icelava

I mostly use DataTables (sometimes DataReader) since pages usually deal with a single table of data. It is quite upsetting to find books and tutorials forever teaching the use of DataSet together with DataAdapter. I wonder how many know the DataAdapter works with DataTables stand alone.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/27/2005 9:47 PM Sean Chase

Interesting Post....There are a ton of built-in features that you get for free: serialization, sorting, DTC bindability, filtering, schema, XML integration, relations, and validation.

"It is recommended that you avoid designs requiring you to transfer data in a custom object-oriented format, because doing so requires custom serialization implementation and can create a performance overhead. Generally, you should use a more data-centric format, such as a DataSet, to pass the data from the data access logic components to the business layers, and then use it to hydrate a custom business entity if you want to work with the data in an object-oriented fashion. In many cases, though, it will be simpler just to work with the business data in a DataSet." - Source: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp

OK, now all of that being said...I'm *not* a fan of DataSets (unless they are typed-DataSets), and even then I'd rather take the time and build my own classes and collections (or use LLBLGen Pro). :-)

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/27/2005 10:19 PM Scott Mitchell

Icelava, a DataSet is a set of DataTables. How are you populating the DataTable, but through a DataAdapter and a Fill()? Yes, a DataTable is more performant than a DataSet, but I'd still wager it's several times less performant than a DataReader.

Sean, my point was that many of those DataSet features are not too useful in an ASP.NET application. The DataSet has a time and place, as my article mentioned, but Web apps are (IMHO) neither the time nor place.

Regarding the quote you posted, Sean, I wouldn't use the serialization techniques for populating a custom object. Rather, just get a DataReader that has the database results, loop through the results one record at a time, and for each record create an instance of the object, assigning the object's properties the appropriate field values in the returned DataReader. This is, for example, how the data is passed around in the ASP.NET Forums software architecture (now Community Server).

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/27/2005 11:30 PM Wessam Zeidan

if you're using webservices in your application that return result sets, then you would want to use a dataset to hold these result sets.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 12:51 AM Barry Kelly

I don't use datasets, but something similar to a dataset that has been built from the ground up to fit in around 500KB for most of our data, but doesn't involve lengthy serialization/deserialization logic. That is, all the data is stored in one big byte array, and read/written on a per-field basis.

Tables, indexes, relational navigation, constraints, are all built into this system. I can't really tell you any more than that.

This byte array can then be stored in SQL Server, or alternatively in some kind of distributed DB: there are a lot of different options on how to share it across a web-server farm.

All the metadata which describes the layout of the "dataset" is initialized only once per app domain at startup, and shared across all threads in that app domain. It's a really neat system.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 2:02 AM Kris van der Mast

Where I currently work we use webservices intensively (read always) so that's why we use typed datasets in every application. Sometimes also custom classes (called valueholders by our architects) but that's rather on an occasional basis.

Grz, Kris.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 3:30 AM James Shaw

Yes, I'm with you on datasets. I use datatables and normally cache the results.

However, there is one place i use a dataset!! It is the only data structure (IIRC) that has the really handy GetXML() method. There are two occasions where I store data in Session that comes from the db - search result ID's is one - and it is really handy to be able to ds.getxml() and then ds.readxml() to restore.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 3:57 AM Dan F

There's really only one spot where I use dataset/datatables, and thats for the last point in your article. We managed to shave about 5 seconds off a thing we were doing by switching to filtering a datatable rather than repeated hits to the dataset. Each hit was fairly small in terms of speed, but when you do it over 1000 times, it all added up :-)

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 4:33 AM Tom Pester

Dan F wrote :
"by switching to filtering a datatable rather than repeated hits to the dataset"

Dont you mean database instead of dateset near the end?

I use dataset only for remoting and for caching .

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 5:28 AM Mark

Since I'm a self taught programmer, the only time I use a dataset is when I'm lifting some of Scott's code to do datagrid paging.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 7:46 AM Scott

I don't usually use DataSets DIRECTLY in a web application. I have used them in simple DAL's and OR mappers i've written to fill domain objects, but my ASP.NET code is hardly ever touching the DataSet directly.

Wessam,

For me, DataSets are too platform specific to use in Web Services. I prefer returning XML serialized arrays of objects. It may require my consumer to do a little bit more work, but it ensures that I have a wider base of consumers.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 7:50 AM Jeffrey Palermo

The only thing I use datasets for is if I need tabular data for read-only purposes. In that case, an array of business objects would be overkill because I don't need any object behavior. I just need the data for display.

Anything else, I use my own custom domain objects.

I don't have an argument for or agains the dataset, but I understand that it is targeted toward RAD development, which is the opposite of GOOD, MAINTAINABLE development.

As people learn more about good OO design, they drop of the DataSet bandwagon one by one.

# Not using DataSets in a WebApp 4/28/2005 8:18 AM Giddy Up!

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 9:57 AM Craig Vitter

Scott, an interesting article.

I tend to use DataSets quite a bit when working with XML documents. For example, I have an application (ASP.net) that gets is display content from a series of XML files. When the application starts I load these files into DataSets (readXML) that are stored in the application's memory.

When getting data from a database I tend to use the datatable as opposed to a datareader. I have a generic DAO that I use to get data and it returns all select statements as a datatable. In ASP.net applications I try to do a lot of caching of frequent requests to Session or Application.

Using the combination of datasets and datatables really streamlines the coding process quite a bit in my opinion. From some of the comments I see here people think that this isn't good OO design.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 12:14 PM Mike

If we're talking about "do I use custom classes (a.k.a. domain model) vs. DataSets (a.k.a. table module)?" then this is just going to spark a religious debate because the reality is one can make a case for both camps and even Fowler et. al. will agree. It is interesting that in PoEAA Fowler pushes the .NET developer towards the table module pattern mostly because of the overwhelming tool support for a table module solution and the almost zero tool support for domain model approach. For my part, having done both approaches, that while domain model is nice to work with it is a very brittle/complex framework to maintain and extend (even with the best OR mapper). The problem is, in my mind, that an object graph representation of data is diametrically opposed to relational storage of said data. By definition then, bridging the object/relational chasm is *always* going to be a non-trivial exercise. Now, if/when object databases become more prominent then I think domain model will be a no-brainer! The architecture I'm working with now is a three assembly approach that's working quite well thank you very much:

1) Business layer assembly.
2) Strongly-typed DataSet assembly (entities)
3) DataAdapter assembly (data access)

Note that 2) doesn't have a dependency on 1) or 3). Also note that 2) and 3) are completely code generated. For the small price of working with entity data in tabular fashion (even though it's strongly-typed) I don't have to worry about binding, sorting, concurrency, etc. all of which I would have on my plate with the domain model approach. The #1 key benefit for me, though, is maintainability of the resultant code base and the rapidity that I can modify/add new functionality. Not to mention the fact that most any .NET developer walking-in off the street is going to be familiar with DataSets/DataAdapters....

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 1:27 PM John Morales

I only use DataSets to when binding to a DataGrid. The DataTable.DefaultView has built in filtering and sorting and it's a natural fit for that kind of thing.

Otherwise, it's SQLDataReader for 90% of the work.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 1:31 PM Scott Mitchell

Mike, you have some good points. I tend to stick to the domain model and prefer that over using more tightly-coupled models with DataSets. I think, in part, it's a tradeoff between runtime performance and coding-time performance. Using the RAD tools and built-in features of the DataSet can improve the coding-time (if that's what the developers working on the project are familiar with), but will undoubtably hurt the performance of the running application.

John, are you caching the DataSet? I still prefer using the DataReader when binding to a DataGrid and filtering/sorting by appropriately adjusting the SQL query used. (More precisely, I typically use custom business objects that are populated based on a DataReader and contain methods for sorting and (if needed) filtering.)

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 1:51 PM Steve Perry

I tend to use datatable out of pure convience. 90% of the time a given page is only working with a very small set of records (10's not hundreds), that is about all most users can handle, if there is more than about 2 or 3 pages in a datagrid, a user will want a way to filter the data, and I'll do the filter in the database stored proc. For a small set of records the performance differance between the datatable and datareader is not even worth talking about.

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/28/2005 2:00 PM Mike Swaim

Datasets provide one nice feature over using custom classes. They maintain state for you, so updating the database is a snap. For me the downside of datasets is that they're not threadsafe. Our apps load metadata as needed, so it's quite possible for one thread to be loading data into a static object while another one is reading data that's already present.
I tend to use custom classes with threadsafe hashtables and arraylists for "static" data.

# Not using DataSets in a WebApp 4/28/2005 9:22 PM Giddy Up!

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/30/2005 2:41 PM Jeff Atwood

> but will undoubtably hurt the performance of the running application

Is performance is the most important criteria for every app you write?

# re: Why I Don't Use DataSets in My ASP.NET Applications 4/30/2005 7:02 PM Bob

I generally use datareaders for anything I can

# Scott Mitchell and his datasets 4/30/2005 7:48 PM Sonu Kapoor's WebLog

# Some interesting finds ... from late last week 5/2/2005 5:35 PM Jason Haley

Some interesting finds ... from late last week

# Scott doesn't use datasets in ASP .NET Applications 5/2/2005 8:07 PM Eric Wise

Scott doesn't.  I do... sometimes.
I generally prefer business objects and collections thereof...

# Scott doesn't use datasets in ASP .NET Applications 5/2/2005 11:57 PM .Net Adventures

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/3/2005 6:32 AM Jason

One useful feature of DataSets is the ability to create relationships between tables. Let's say you have a database with an entity "Book", which has a 1..n relationship with entity "Author" and a 1..n relationship with "category."

You can write a stored procedure "GetBookInfo" that returns a datatable for the book's attributes, a datatable for authors and a datatable for the categories.

You can then use the stored procedure to populate the datatable with all three tables, and create a relationship between the three.

Is there a better way to produce the same results?

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/3/2005 1:15 PM Jeff Handley

Well, my decision process for whether or not to use a DataSet (or DataTable) is not black and white, although it is fairly straight-forward.

I've documented my decision process on my blog (http://jeffhandley.blogspot.com/2005/04/shouldusedataset.html) and I decided to document it in code format, just because that was fun!

This is always a good debate though!

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/3/2005 3:59 PM Ye

There are circumstances where a DataSet is a better choice than a DataReader. I wouldn't say one should not use DataSet altogether even in an ASP.NET application. John Papa's article has a more complete description of those circumstances. My <a href="http://kuantanzai.blogspot.com/2005/05/dataset-vs-datareader.html" target="_blank">blog</a> attempts to provide a slightly different perspective about this debate.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/4/2005 12:14 AM Errol

All in all it was a good article, and I read it because I think datareaders are cool and have their uses. Explore using a datareader if you haven't already, and then decide.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/4/2005 8:53 AM Dave C

The question should not be whether to use DataSets or DataReaders because DataSets also use DataReaders to populate the tables. The question should be "Where am I going to store the data that comes in when I use DataReader by itself?" If you bind directly to the controls, then the data has to be re-read from the database everytime the page is posted. If you store the data in a collection or array list, then you are comparing DataSets to collections rather than to DataReaders. That is a different comparison.

For read-only display data, Scott may have point. But for Web sites that collect information from the user and pass it back to the database, DataSets (or DataTables) are much more efficient because the data adapters have the update methods already constructed (auto generated code).

SQL Server 2005 throughs another factor in the discussion with support for MARS (multiple active result sets) where several tables can be returned from a connection simultaneously. Matching these resultsets to tables in a DataSet is a natural fit. Then the app can dish out the data to users as needed from memory.

Dave C

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/4/2005 9:05 AM Gary T

Nice one.. I thought is was only me that didn't like using datasets in web app. It just seems to make sence to use a disconnected data method in a disconnected, stateless environment such a web app. And then let the back end database do what it was designed to do... look after the data and the relationships between the tables.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/4/2005 9:54 AM Yaakov

Dave C - I think that when you bind to a control, the data does NOT need to be re-read from the database everytime the page is posted. Assuming that you are using your ViewState, the data will only need to be re-read if/when you make any modifications to the data and want to reload the control. (For the record, so far in my programming I have only used (Sql)DataReaders).

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/4/2005 1:34 PM Memi Lavi

I think Dave C is right. The real question is not whether to use DataSet or DataReader. Every self-respected web application will have a clear seperation between the DB, BL and UI layers, and by binding the, say, DataGrid directly to the DataReader, you actually push the DB layer straight into the UI layer, and that's BAD.
So the real dillema is between DataSet and some other custom objects / collection. This is where the DataSet really shines - sorting, paging, concurrency, automatic updates - I really don't see an argument here.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/4/2005 1:51 PM Norm B

I generally don't like DataSets in web apps either. However, I use one effetcively for the website I maintain for my church. For the "Announcemens" page, the announcements always have a title followed by the body of the announcement. To maintain the announcements page, I created a password-protected admin page that utilizes a data table bound to a DataSet. Whenever I want to edit an annoucnement, I simply invoke the Edit command, do my editing, then invoke the Update command, and rebind mt DataList to the dataset with the updated information.

I could have used customer classes and collections, but since the list of announcements is rarely longer than 25 items, this approach works rather well and is speedy enough.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/4/2005 2:14 PM Hanan M

I'm not sure what my opinion is on this topic. I am rookie to intermeidate with ASP 3.0.

I'm started learning ASP just when .Net was becoming mainstream (at least for mid to large size businesses). The thing that struck me about ASP was how developers always insisted on saving server resources down to tiny sessoin variables.

As I recently started learning ASP .NET(yet to develop a full blown app), Datasets confused me. Not becuase of their logic, but becuase how ubiquitous Datasets have become. As if server resources aren't scarce anymore.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/5/2005 5:56 AM Ian

There is always a trade off between performance between performance and maintainability. In our case we get pretty good performance using typed datasets as well as high degree of maintainability. Although I'm sure we could squeeze some more performance out of our app by using datareaders, we would be sacrificing maintainability as well as compromising the speed with which we can adapt to changes in a complex evolving project. Given that our users don't perceive any performance problems it would be pretty dumb to switch to using datareaders just because they are faster and as a result increase our development times considerably.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/5/2005 1:42 PM Jeffrey Palermo

Posts like these are really valuable for newbie developers. I think the bottom line is not to make a blanket rule, but if you use a particular method, know why you are using it. My impression is the some devs read "Learn .Net in 10 days", and then they start dragging and dropping datasets, and they don't know why they are doing it other than "it works on my box".

# Datasets in ASP.NET 5/5/2005 4:31 PM JOEL'S BLOG

# Datasets in ASP.NET 5/5/2005 4:33 PM Joel's Virtual Desktop

# Datasets in ASP.NET 5/5/2005 4:33 PM Joel Ross

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/5/2005 6:21 PM Ben

I used dataset in a different way from most traditional user. I am using this design for a while and i found it quite good
<br/>
First, I use typed dataset (eg, A Customer dataset) as a business entity
<br/>
Second, I use datareader to fill the dataset instead of dataadapter, there are many advantages here. The best advantage here is to completely seperate the column name of the database with the dataset. You don't need to change the column name in the business layer and the presentation layer. In typed dataset, you can also use Enum as a type (but you have to modify the auto generated dataset code for yourself). Another great advantage is that, using datareader to fill up the dataset allows you to customerize the way you fill up the dataset, you can write 10 sql and use datareader to put the data into the dataset, in whatever way you like.. I use it for object relational mapping (OR Mapping)...
<br/>
The down side of this approach is it is slower

# Encapsulation 5/6/2005 12:03 AM Sean McElroy

The reason I prefer the domain model is to encapsulate my data in a way that makes more OO sense to me. I agree with Mike that this approach is more brittle, but I believe it's more 'technically correct' in my mind at least. My database tables are entities and my classes should mostly be entities too. Sure, you have all sorts of little weird utility classes in an application, but by storing entity data in a utility class like a DataSet, my data and methods aren't grouped together in a way that makes as much logical sense to me. As far as tier seperation is concerned, when I use a solution that depends on DataSets and DataAdapters, I find myself often using these DB layer methods at the presentation layer far more often than the domain approach, where I store them in collections exposed as properties at the BL layer.

My two cents, at least.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/6/2005 8:44 AM Jay Patel

I would prefer to use custom classes than DataSets, but would hope to use some tool to generate and 'map' db columns to the custom class data members. Does anyone know of any such tool? Do any of the OpenSource projects have any such mapping and/or code generation tool (NPersist, NHibernate, IBatis [http://www.ibatis.com/index.html], etc.)?

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/6/2005 9:04 AM Mike

In Whidbey (VS2005) the decision gets a bit harder (but mostly easier!) with partial classes and generics.

If you're pursuing the domain model approach, your job gets a bit easier primarily because you have a lot less code to write (e.g. all your typed collections, etc.) You still have to handle change tracking (i.e. updates/deletes/inserts using a unit of work pattern, etc.) for your collections but at least you can push all of this into one generic type. Note that you still need to roll your own entity/collection binding implementation and sorting scheme and VS2005 doesn't help you here.

Things get better as well with the strongly-typed DataSet approach. The MSDataSetGenerator now emits the DataSet code as a partial class which *greatly* improves the story as you can now hook-in all the way to the metal (before you could only sub-class the DataSet and couldn't touch the private/internal bits...) The remoting performance of DataSets has been greatly improved as well with true binary serialization.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/6/2005 9:42 AM Mike

Jay,

I actually did some pretty extensive O/R mapper research not too long ago and can pretty much write all of them off (for a variety of reasons I won't go into here) with the exception of two (both commercial but reasonable $$$): LLBLGenPro and DeKlarit. Both are fantastic tools but differ slightly in philosophy.

DeKlarit (http://www.deklarit.com) takes a hands-off approach to the database and wants to own the schema. The generated domain model entities internally use DataSets to marshal the data to/from the database. This is a great tool especially for shops that don't have (or want) very deep DBA talent. Andres Aguiar (http://weblogs.asp.net/aaguiar) is the chief architect of the product.

LLBLGenPro (http://www.llblgen.com) is a more "pure" O/R mapper in the sense that it builds a rich domain model upon just the basic framework primitives using well-known and accepted design patterns. The generated code is well-architected and has multitude of customization hooks and configuration options. If you'd like to retain a bit more control over the database and its schema then LLBLGenPro is definitely the way to go. Probably a bit easier sell to your resident DBA...Frans Bouma (http://weblogs.asp.net/fbouma) is the chief architect of the product.

Like I said though, both are excellent tools and would work well if you decide to take the more onerous domain model approach...

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/6/2005 12:53 PM Ben Scheirman

To those of you who are advocating DataSets for return values of webservices, you should really reconsider your design.

A DataSet is tied to your database schema... sure it's easy to get data in/out, but you are providing details of the inner-most part of your application to the outside world. Seriously, your UI developers don't even HAVE to know what the database looks like. For the same reason why we use public properties to access the paired private counterparts... you are encapsulating your inner workings from anyone outside the class.

Answer this, what happens when your DBA decides to change the name of a column of one of the tables? BOOM! He (unknowingly) just broke ALL of the clients of the webservice, since they all reference the same column identifier.

DataSets have their use, sure... but I wouldn't ever replace my domain model with DataSets.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/6/2005 3:40 PM steve Perry

Ben, If your DBA is changing column names on you you've got bigger problems. The database column names are as much of a contractual interface as your web service interface is. If the name of a column is changes chances are its definition has changed also, which implies that the old column/data is gone and has been replace with something else. So all your front end are going to need to be updated anyway to reflect this new definition.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/8/2005 8:03 PM Ben

Steve, i am aware of that. Database column ares are usually not changed. But my story is with typed dataset and datareader using TOGETHER, it gives you a greater flexibility. For example, you can put enum as a column type. there is no enum type in the sql server.
In the dataset, and when you are filling the dataset using datareader, you can map the enum values into the dataset...

I use dataset instead of class as a business entity becasue it allows me to do sorting and filtering very easily... I always come accross with the code where I can do sorting and filtering in the business class. With class, it is a painful task to do sophisticated sorting and filtering

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/8/2005 8:05 PM Ben

but business class definitely gives me some advantages over dataset, it allows inheritance... So my own rule of using business class and typed dataset is, If the situation requires sorting and filtering, then I use dataset, if not, then I use business class

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/9/2005 3:39 AM XGR131

It is really good article, but obviously you missed on using DataTable.
Of course DataSets are expensive in programming terms, but DataTable is a good alternative.

In conclusion: Yes DataReaders Should be used over DataSets, But DataTables should be used over the DataReaders for their inbuilt functionality.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/10/2005 11:50 AM westmich

There are two reasons that came to mind when I first started reading this article that I haven't seen mentioned yet. 1) It's simple to derive a dataview from a dataset and then have access to the count property and other members only in a dataview. 2) Correct if I am wrong, but doesn't the datagrid require a dataset for certain features like paging and sorting?

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/10/2005 1:49 PM Lynn

I've ventured down both paths and came to the conclusion to use the dataset over custom objects for complex data requests. It may be a heaver object, but it's very powerful and very flexable. If your pulling back a large set of relational or semi-relational data it's extraordinarily convenient and easy to implement. The features and services are just to compelling to ignore. BTW/ you can do custom column mapping by creating a custom DataTableMapping object and applying it to an adapter on fill or update.

However, if you retrieving a simple object, say for membership credentials, it doesn't make much sence. Under those circumstances I find it easier just to build a custom entity and fill it with the datareader. The data reader is very nice and fast, but if you directly bind it to a page forget N-Tier development becasue it cannot be remoted.

I'm in a two man shop so I have to ride the wave of tools that MS is building. Here's a glempse at where MS is going with data:

http://www.xml.com/lpt/a/2005/01/12/comega.html

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/10/2005 4:15 PM Gavrilo Princip

I like to use a dataset to populate my hompage because i can run a single stored procuedure that returns 4 diff results sets, one for each section of the page. Headlines, features, new reviews and gadget.

am i retarded? i just like executing one procedure disconnecting then binding to the different controls (grids,lists) on the page.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/11/2005 3:56 PM Tom

I don't use the DataSet either.

I use the DataReader and put up the output - it runs like lightning. I hand code any column sorting and filtering, which takes only a few lines of code (old ASP code, mostly!-)

Where we're contracting, the in-house developers (newbies with little or no ASP/ASP.NET WWW experience) complained about our non-use (abuse?-) of the DataSet.

So we benchmarked against them. In side-by-side comparisons our code was quicker and the memory footprint was smaller. And to boot the code is easy to follow (although very procedural). Needless to say, they've seen the light.

Seems that the lessons that applied to ASP also apply to ASP.NET.

I'm sorry to hear that this well-kept secret is now getting out - it was a strategic advantage for our firm.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/12/2005 3:41 AM Ishak

what Gavrilo Princip say is the same with me. so, how make it simple if we want return more than one resultset at once connection ?

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/12/2005 6:22 AM Nathan Pond

Hey Scott, long time no talk!

I generally agree with your reasoning, because performance is a big issue. However my big problem with using datareaders is that you don't have access to output params or return values from stored procedures until after you iterate through every record in the datareader.

In my last large project, we used output parameters in numerous occasions, and also used the return value to specify non-fatal errors we may have run into in stored procedure execution. Using a datareader, we would have had to already process all the data before checking the return value to see what we should do with the data, whereas using datasets/datatables/datarows we could handle all of that in the data access layer as well as pass back the output params in byref parameters to the DAL routine.

I guess the ideal solution for performance would be to use a datareader when you can, and only deviate when you must. However, in a horizontal development environment this isn't always easy. That's why we chose to go soley disconnected in our data layer, made it easy for the interface programmers. :-)

You are right though, in simple apps (probably 99% of web projects) you won't encounter these drawbacks and datareaders are the way to go.

Good to see you still around!

-Nathan

# Sorting, Paging, and update Strategies 5/12/2005 8:23 AM Jose Morinho

How would you handle sorting, paging and updating if you fill a datareader into a datagrid?

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/12/2005 11:39 PM Javier Luna

I believe that any DataLayer must be a simple code block, that they allow operations against DB.

That code block would not have to know on the Business Entities. Single to specialize it is to execute the operations (Store Procedures and SQL Sentences) against the engine DB (SQL, Oracle, DB2, etc.), with which this setting.

Finally, I invite to you to download the DataLayer.Primitives Public Version.

This is very cool Data Layer :)

DataLayer.Primitives - Readme!
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1389

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/13/2005 5:15 PM David

I totally agree with Scott on this one. The DataSet, although a very novel disconnected design, brings with it a rather complex model to support. The more they work into your architecture, the more cumbersome things can become. That statement comes from using them for things like reading XML into the DataSet and having to do a bunch of customized sorting. The syntax is right down bewildering...

My personal approach is using business objects. There are a lot of reasons they end up being highly valuable. One of those reasons is the ability to port designs into other OO languages like Java.

I am using a "home spun" approach to using objects in-place of DataSets. You can get more on the idea at this url...

http://blog.btek.net/PermaLink.aspx?guid=1975962e-6e5d-4f78-b5eb-090516bd89e8

I was a huge advocate and had the whole DataSet stuff forced down my throat from a "top 3" consulting firm. I did use them and they are still in my architectures. But, from now on I think I am sticking to good old business objects...

Thanks Scott for this posting...

# More On Why I Don't Use DataSets in My ASP.NET Applications 5/16/2005 8:38 PM Scott on Writing

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 11:40 AM Garrett

Performant means "a performer". You can't be more performer. More efficient, higher performing, or it's way faster are better ways to describe it than co-opting performant. Great article seems like the same old arguments from ADO days. Command vs. Recordset??

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 7:16 PM JT

How about datasets in ASP.NET 2.0 Scott? Does the same logic applied to it as well?
Thanks..

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/18/2005 8:24 AM MS

I ran an informal test of DataTable vs. DataReader performance. I filled a business object 10,000 times over several tests with both methods from SQL Server.

The DataReader performed 33% faster, but the per object cost was measured in less than milliseconds.

# re: Reasons Yes to use datasets 5/18/2005 10:08 PM Leo Muller

Until I read your article, I didn't realize how much faster datareaders are, and I will definitely start using them where possible.
I've seen lots of programmers, who forget to close their datareaders, thinking that the "garbage collector" will do this for them. This is not true, the connections will stay open and you will run out of connections in your connection pool.
There are a few places that I would not use datareaders:
1) Sorting: my prefered way of sorting data is to do create a dataview from my datatable, and use the Sort property. I will save in viewstate, or session previous sorts, so I can sort ASC and DESC, and different fields, without any SQL changes (especially nice since I use stored procedures), and all that with one basic function.
2) Caching. You can cache the dataset object, which will make it very fast, since it resides in memory. Combine this with sorting, paging, multiple pages, and you will get a lot of performance gain.
3) With the dataset you can move forward and backwards on the records. You have a rowcount. This makes it very flexible to work with.

Anyway, thanks for the great insight of this.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/18/2005 11:08 PM Hardik Trivedi

Hi Comrades!! The "Type DataSet" is one of the building block at the architecture-design time. Its generally the good practice to design generic(Not one then three-four) "Type Dataset" for your business class, which is dedicated for "READING"(like LoginRead, BookRead). And all of the methods return the data in either of the type-dataset format and return it to callee. And also for the "Mass-Update", in conjuction with the "sp_xml_preparedocument"(SQL Server 2000) "Dataset" is the BEST option.

What I am really trying to portray: Selecting the specific methodology(either DR or DS), depends upon your project designing. Its "Development Time VS Product Performance".

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/20/2005 8:46 AM Van

My understanding is that the datareader needs the connection to the database to function. If I have a layered design with a Business Service that calls a Data Access Layer how would you maintain the connection back to the UI layer where it is used? Don't you want all your database logic including closing the connection in the data layer?

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/20/2005 9:03 AM David Cornelson

I blogged about this too. (http://dave.cornelson.net/PermaLink.aspx/b8edaef7-017a-4df5-97af-0788e71b5f2e)

No DataSets for me please and I have an anecdote from a client. I added a few screens to a webapp that had been built entirely with DataSets. I asked if I had to follow the architecture and the client said no, especially if I could make the screens faster. So I built my own entity classes and used DataReaders. When I delivered the screens to the test team, they all asked the same question at first, "Why are these screens so much faster than the old ones?"

Once you train developers to use entity classes and datareaders, build some codegen tools in-house, the benefits far outweight (in my opinion) whatever benefits come from using DataSets.

The DataSet is not only wasteful, but as far as I'm concerned, very hard to maintain code around. Whenever I see the code for a strongly-typed DataSet, I get a headache.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/22/2005 4:40 AM Adriana Stamat

I don't use datasets. Actually, I see no reason to use datasets instead of DataReaders in an ASP.NET app. Datasets means XML, which means memory... Why to do that? Let the database do it's job, use paging, sorting, filtering in stored procedures, this is what they are for... I my web app, in user interface I use the IDataReader interface to bind data to the controls. I my DAL I use only datareaders to return the data to the UI layes (as IDataReaders). Look at the Data Access Application Blocks from Microsoft Enterprise Library - Using a DataReader to retreive multiple rows.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/23/2005 2:11 PM Dave S

I have stopped using datareaders in my web applications because if there are multiple users connected to the same table, the datareader would lock the table even if the data was only being read. A dataset is disconnected from the table as soon as its called. I am surprised that no one else here has seen this problem. Let me know if you anyone has a solution

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/24/2005 7:58 AM Brett Rogers

I'm an ASP jockey who's wading into ASP.NET for the first time, in an enterprise intranet environment with 10,000 users.

Speed increases usability and efficiency, so I'm glad to find your article, Scott. I'm assuming that given your breadth of experience with DataReaders and your support of their use, Dave S' (previous comment) about "locking the table" has to be a cleanup issue in code or something.

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/24/2005 10:32 AM J B

Dave S has some points that amaze me as to how little they are thought about sometimes. If you're pulling 10,000 records down with a reader, it'll lock that table for a while, and when you have a limited amount of connections to a database, it'll show.

As far as DataSets tying to your DB schema, that's what stored procs are for. Datasets are extremely helpful in setting up relationships between different entities, and you don't have to return a DataSet directly from an XML web service, you can return just the XML data via an XmlDataDocument (or even better, using the open-source Mvp.Xml library which lets you return Xml using an XmlReader).

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/25/2005 1:33 AM Sam

Im ok with u JB

that is my use of dataset :

My DataSet is cached.

I use it coz my web application could be able to use an Oracle or SQL Server or other database engine... with it, i'm totaly independant from data source.

My web application is totaly based on this dataset, so it can still work even if the database is out... much appreciate.

ex : http://www.nantes.cci.fr

My DataSet is not cached

Statistics : i had to review an application which was making recursive querys (beurk). It was done one time by day and it tooks 15 minutes. Using DataSet i reduced it to 0.1 minute...


I still use datareaders in some others applications... it depends on many things.

sorry for my english :)

# re: Why I Don't Use DataSets in My ASP.NET Applications 5/26/2005 7:26 AM Mr. Anonymous

Datasets do not promote good OO design. How can you model a domain with a Dataset, or a Datatable, or whatever? It just doesn't work. I've used typed Datasets to try to bake in business logic as well. It's a travesty. There are plenty of tools that will generate your domain classes for you (based on the database schema), whereupon you can add custom business logic to them. Use an O/R mapper to persist to the data store, and possibly drop down to use ADO.NET with DataReaders and Datasets when absolutely necessary.

# re: Why I Don't Use DataSets in My ASP.NET Applications 6/13/2005 7:20 AM >.NET

Hey guys,

Good stuff by Scott, but there's a fantastic article on dotnetjunkies.com - Dynamic DataGrid Paging and Sorting Using A DataReader - http://www.dotnetjunkies.com/HowTo/3F9C7FED-BFDB-49CC-BAF9-442079430EB2.dcik - dealing with the datareader/datagrid issue and it shows two ways of using the datareader to bind a datagrid and still maintain paging, dual-directional sorting and caching. Simply awesome.

So glad I found it!

# re: Why I Don't Use DataSets in My ASP.NET Applications 6/13/2005 11:23 AM Derek

I'm with u, I just read the article and it has shown me some new ways to deal with the datagrid using a datareader that I didn't even know. Aside from serializing the data, and other things perhaps, I am gonna use the techniques in the article from now on!

# re: Why I Don't Use DataSets in My ASP.NET Applications 6/13/2005 12:53 PM erik

"For each record you'd create an instance of the custom class, set its properties to the field values of the query, and add the custom class to an ArrayList (or, preferably, a strongly-typed collection object). You'd then cache this collection of custom objects."

Could you provide a sample of this? In the related article (An Extensive Examination of the DataGrid Web Control: Part 14) your code is commented.

# re: Why I Don't Use DataSets in My ASP.NET Applications 6/27/2005 11:07 AM M

How about this
1) Populate dataset on first request
2) Cache dataset
3) Returned cached version at every subsequet request

I have stellar performance with this approach!

# re: Why I Don't Use DataSets in My ASP.NET Applications 6/27/2005 11:12 AM Scott Mitchell

M, here's a problem with that approach. After step (2) said data changes. Now you're showing users stale data. :-(

(Of course this problem goes away with 2.0 and SQL caching dependencies... see http://www.15seconds.com/issue/040518.htm for more info...)

# re: Why I Don't Use DataSets in My ASP.NET Applications 6/28/2005 3:42 AM M

Aha! But whenever an update occcurs i invalidate the cache. When the user requests it next - fresh shiny data.

# re: Why I Don't Use DataSets in My ASP.NET Applications 7/7/2005 10:44 AM sw

There are instances where you cannot rely on viewstate to hold the data in the component you bind to the DataReader.

If I have a datagrid with 30,000 rows and I want to use paging, I need a datatable (or dataset) to hold and cache the data between reads.

If I use a DataReader, I would have a few options:
- Requery the database each request
- Use the viewstate, but send all 30000 rows to the client

If you look at the page weight (ie. the size of the aspx) and response times, you would see a huge increase by not having to Post and Send a few MB of data..

# re: Why I Don't Use DataSets in My ASP.NET Applications 7/7/2005 12:24 PM Jason

Any solutions on how to pass a datareader back from a data layer?

A reader is closing in the Data Layer before I can use it in my page, so I'm sticking with Data Tables until I can find a solution.

# re: Why I Don't Use DataSets in My ASP.NET Applications 7/7/2005 12:33 PM Thomas

Has anyone checked out - DataGrid Paging and Sorting Using A DataReader [http://www.dotnetjunkies.com/HowTo/3F9C7FED-BFDB-49CC-BAF9-442079430EB2.dcik]?

These forum posts are all I believe dealt with in this article.

It really show shome great ways to use the datareader's speed with a datagrid and not lose any functionality, aside from any data editing. So say NO to the DataSet :-)

Anyway, I wanted to praise Dimitrios on his really awesome article!

-Tom

# re: Why I Don't Use DataSets in My ASP.NET Applications 7/7/2005 9:10 PM Craig B.

Ditto on that. Very nice.

# re: Why I Don't Use DataSets in My ASP.NET Applications 8/12/2005 8:55 AM Kevin

I'll be giving Dimitrios code a try since my major reason for using a Dataset is for paging and sorting. He also demonstrates caching.

Hey Scott, great subject here it really brought up an issue I wish I never knew...LOL

but perhaps you should review the 4guys code that uses Datasets "unnecessarily" like this page?
http://www.4guysfromrolla.com/webtech/072101-1.shtml
and this one uses a DataTable
http://aspnet.4guysfromrolla.com/articles/011205-1.aspx
(hey, where's the VB version???)

both great examples btw...

what about practice what you preach? ...hhhmmmm...?...lol

thx again m8!

# re: Why I Don't Use DataSets in My ASP.NET Applications 8/12/2005 12:10 PM Daniel V

Whats the cost in terms of memory for caching a dataset on the web server vs reading from an SQL Server database an average of 8000 times per request.? :) And whats the difference between caching 1 dataset with 26000 words vs 26 smaller datasets with about a 1000 words each?

# re: Why I Don't Use DataSets in My ASP.NET Applications 9/20/2005 1:06 AM Jason Finch

RE: Jay Patel
Do any of the OpenSource projects have any such mapping and/or code generation tool (NPersist, NHibernate, IBatis

----------------------------------
Jay,
I know that both Codesmith and MyGeneration http://www.mygeneration.com both have templates to create NHibernate (& others) mapping files & object classes.

I've moved over from datasets to NHibernate and am loving it.

# re: Why I Don't Use DataSets in My ASP.NET Applications 12/8/2005 12:01 AM Rushikesh

Simply gr8 article and also a good blog tree, i'll rate 10 out of 10 for this.

# re: Why I Don't Use DataSets in My ASP.NET Applications 1/20/2006 1:31 PM Bilal Haidar

Hello Scott:
I tend to use more the Domain Model. But I have one question here.
As you know DataReaders are database-related, in a sense you have the OleDb and Sql datareaders, how do you maintain multi-database usage for your application while using DataReaders? Or you are always sure that you will be using for example Sql Server?
I usually have 3 layers:
1- Object Layer: contains all my custom objects
2- Business Layer (Manager), has all the method applied on the custom objects like "Delte,Insert,Get,etc..."
3- Data Layer, which does all the data related stuff, returns datareaders to the business layer where they are transformed into custom objects.

Thanks a lot.

# re: Why I Don't Use DataSets in My ASP.NET Applications 1/23/2006 10:18 AM Scott Mitchell

Bilal, there are provider-independent DataReader interfaces - IDataReader, which can be used with IDbConnection interfaced-objects. This is the pattern used in the Enterprise Library (see http://aspnet.4guysfromrolla.com/articles/030905-1.aspx for more info).

# re: Why I Don't Use DataSets in My ASP.NET Applications 1/23/2006 11:02 AM Bilal Haidar

Hello Scott:
Thanks for the information. To me using the DAAB requires some additional configuration files, but yet it is a solution. I have also seen the DatabaseHelper @ DotNetBips.com, by Bipin Joshi, it has the same idea I guess.

Thanks again.

# re: Why I Don't Use DataSets in My ASP.NET Applications 1/31/2006 10:24 PM Daniel Ferreira Jorge

Hi, my name is daniel and im from Brasil.

The whole thing about DataReader X DataSet:

To populate a DataSet from a DataAdapter we use the method Fill, and the DataReader doesn't have this method.

But if we look carefully into the class DbDataAdapter, class that every DataAdapter inherits from, we will see that this class expose a Protected and Overloaded method Fill. And the better is: that method can take an object IDataReader as argument.

Its sintaxe is: Overloads Protected Overridable Function Fill(DataSet, String, IDataReader, Integer, Integer) As Integer

SO, WE CAN USE THIS METHOD THRU REFLECTION, BECAUSE THEY ARE PROTECTED...

So, we can create a method, function or procedure to populate a DataTable from a DataReader. Look at the sample:

------------------------------------------------------------------------

Sub PopulateDataSetFromDataReader(ByVal ds As DataSet, ByVal table As String, ByVal dr As IDataReader)
' Create a DataAdapter of the same type of a DataReader
Dim typeDataReader As Type = CObj(dr).GetType
Dim nameType As String = typeDataReader.FullName.Replace("DataReader", "DataAdapter")
Dim typeDataAdapter As Type = typeDataReader.Assembly.GetType(nameType)
Dim da As Object = Activator.CreateInstance(typeDataAdapter)
' invoke the protected method Fill that takes an object IDataReader
Dim args() As Object = {ds, table, dr, 0, 999999}
typeDataAdapter.InvokeMember("Fill", BindingFlags.InvokeMethod Or BindingFlags.NonPublic Or BindingFlags.Instance, Nothing, da, args)
' close the DataReader
dr.Close()
End Sub
-------------------------------------------------------------------------------

Now, a sample on how to use this Sub:

-------------------------------------------------------------------------------

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim cn As New SqlConnection("server=(local);trusted_connection=true;database=Northwind;Integrated Security=SSPI")
cn.Open()
Dim cm As New SqlCommand("SELECT * FROM Employees", cn)
Dim dr As SqlDataReader = cm.ExecuteReader
Dim ds As New DataSet
PopulateDataSetFromDataReader(ds, "Employees", dr)
DataGrid1.DataSource = ds.Tables("Employees")
End Sub

-------------------------------------------------------------------------------

This workaround can significantly improve the dataset performance, because it substitute the DataAdapter with a DataReader

My

# re: Why I Don't Use DataSets in My ASP.NET Applications 2/13/2006 6:48 AM Theodore Kang

I've been following Scott's principles on using the datareader for some small internal/admin maintenance utilities that I have been developing for a client. In this scenario it works well.

I'm curious in a large environment how one would handle concurrency checking without using datasets? I guess you could retain the original values in the same class/collection? Then perform a precheck prior to writing any changes back to the database? Has anybody tried to implement something like this?

# re: Why I Don't Use DataSets in My ASP.NET Applications 12/19/2006 2:17 AM Salman

Hi there, great article, great blog.

I am new to ASP.NET, doing my first project in .NET 2. I have a question.

I am using ObjectDataSource to populate GridViews. The SelectMethod in my classes returns SqlDataReader object, which means that the GridView is bound directly to a SqlDataReader. Nowhere in my code i call the close method on SqlDataReader. I understand that its necessary to call SqlDataReader's close method.

My question is, does Close method of the data reader gets automatically called when binding to GridView, or is it just a really bad idea to do such binding? The alternative would be to return DataTable from select methods.

Any comments would really be appreciated...

Salman.

# re: Why I Don't Use DataSets in My ASP.NET Applications 12/22/2006 3:58 PM Salman

Ok, here is what i found. The GridView apparently does close the datareader. So, in my opinion there is nothing wrong with binding a GridView directly to a SqlDataReader.

Salman.

# re: Why I Don't Use DataSets in My ASP.NET Applications 2/21/2007 7:31 PM Lucas Goodwin

There seems to be a GREAT deal of misconception about DataSets, DataTables, DataReaders, and DataAdapters.

First, if you’re using an OR/M system then all these points are void. A good OR/M should generate all this code for you anyways.

DataSets/Tables and DataAdapters USE Data Readers for filling! Don’t bother filling a dataset with anything but a DataAdapter. Secondly, DataAdapters are only absurdly slow when using SqlCommandBuilders to build the CRUD commands. You can build your own commands and set the DataAdapter to use them instead.

Additionally, DataSets are supposed to be used as a disconnected DB. Once the DataSet is filled it is no long attached to the DB until you call an update on it. Update will then process ALL changes to the dataset since it was last updated/filled. DRAMATICALLY reduces development time.

Finally, my “Advice” on DataSet vs DataReader (For those not using OR/M). If you’re not trying to enforce relations or do multiple changes in one update then a collection of a custom data-containers filled with a DataReader is most certainly the way to go. Greater control, easier to maintain, etc. But as soon as a disconnected (As in many changes before each update) behavior is needed, I’d most certainly go with the DataSet.

You can always roll your own later if performance is proven to be an issue. Learn what the Game Developers learned long ago. Don’t Optimize until after profiling!

Title:
Name:
Url:
Enter the code you see:
Comments
Remember Me?