Scott on Writing

Feedback

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 6:07 AM John Christensen

I tend to agree with you, and in fact go further: I won't, generally, touch DataSets at all, whether in ASP.NET or Windows.Forms. They're a slow, bloated way to duplicate your database structure, while adding the headaches of having to figure out how to sychronize content, but without usefully solving the impedence mismatch between a relational database and an object-oriented application. I'd much rather use DataReaders to fill business objects and let consumers of those objects not care overly much about the specifics of the store used to persist those object's data, generally only that they need to pass in a connection string, some sort of table prefix, and occasionally they may have to call a save method.

Right now I'm looking with great interest at ObjectSpaces, slated to be released with Yukon (the last I heard, at least). From what I've read about it, it seems like a wonderful solution to the impedence mismatch problem.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 10:01 AM stephen patten

Thanks Scott!

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 10:33 AM Sean Chase

As far as DataReaders vs. DataSet goes - DataReader is faster - period. Does it always make sense to use? No. I can't tell you how many times I've seen ASP.NET apps come crashing down because someone didn't close a DataReader in their code and ended up running out of connections in the connection pool, so be careful! The extra functionality in the DataSet is one reason that back in version 1.0 I went from using DataReader everywhere to using DataSet. Oh, and don't even think about passing a DataReader between tiers - you lose too much control and someone will more than likely NOT clean them up (dispose/close) correctly somewhere below the BL stack.

Custom Objects vs.. DataSet - there is *so much* gray area here. Personally, if I have time I'd rather roll my own object model. I think DataSets are a really bad idea for use in an object model. Typed-DataSets are much better if you want to make that case, but at the end of the day you are talking about a Data Transfer Object (DTO), not a business object. This is one reason that I'm writing a proof-of-concept application using LLBLGen Pro and getting out of the typed-DataSet mode. Don't get me wrong, I think typed-DataSets are great. You get XML functionality, sorting, filtering, relationships, on and on and on. But if I'm going to go that route personally, it would have to be for a smaller-scale Web application where I'm calling from a page to a stored proc to get back a set of data and then binding to a page. DataSets/DataTables/DataViews are great for that.

Web Services and DataSets - A very, very bad idea. That is unless you don't care at all about interoperability and a huge payload. Take a look at Aaron Skonnard's blog. I've gleaned some pretty major benefits from the contract-first approach. Create your XSDs for the Web Service input and output, using xsd.exe to create the classes based on the schema (or some other tool) and use those classes as DTOs. The DTOs are not part of the business logic object model, just an adapter for the service interface layer.

Bottom Line: I prefer the custom object approach over DataSets in an object model any day. I'd much rather use typed-DataSets than DataSets if using that approach in an application. DataReaders can be dangerous if you don't dispose of them (dispose/close) correctly. Use common sense, there's more than one answer to any given problem. Just my $.02.

Very interesting discussion!

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 10:58 AM Jeffrey Palermo

Everyone can argue and compare performance numbers in different scenarios to justify one versus the other. The real argument, I think, is design. No matter what you do, your application must perform well enough to meet the customer's expectations. The customer doesn't care about the internal workings. So what other motivations do we have. What about OO design. What about an object owning state and all behavior that goes with that state? A DataSet cannot substitue for a domain object. It has no custom behavior. It holds records. As long as DataSets are pulled and bound to the UI, the application will be of Procedural nature. I'm coming from a stand-point where I care about OO and the maintainability and testability gains associated with it, so DataSets don't hold much weight with me. This comment is getting long, so I'll just post about it.

# The _real_ reason to shy away from DataSets - level 300 5/17/2005 11:18 AM Jeffrey Palermo

The _real_ reason to shy away from DataSets - level 300

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 1:36 PM MAS

Would you use still use a DataSet for the ASP.NET 2.0 TreeView control?

The MDSN example uses a DataSet.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/treeview.asp

Can this parent-child node relationship be accomplished without a DataSet?

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 4:38 PM Shawn B.

I don't use DataSets. I fill DataTables instead, and then, only if I'm not using a custom object. I'll fill the custom objects with a reader. I'll use a DataTable if being used as a datatransfer object (to be passed between the tiers).


Thanks,
Shawn

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 7:47 PM Cheng Yuan Yap Ye

I agree with Scott that it all boils down to what you are after: design time efficiency or runtime efficiency. Is the runtime efficiency gained by using a DataReader worth the design time lost designing those classes to represent the objects?

Jeffrey Palermo makes a good point that the domain model is the best way to go design wise. I whole-heartedly agree.

However, depending on how complex your classes are, in some circumstances a DataSet can be faster than a DataReader.

I have a full article on my blog elaborating further.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/17/2005 11:10 PM Marcus S

I love datasets and datatables. The Select method on a datatable is very useful, and I amk tired of writing my own components when Bill in his infinite wisdom has given us what we need. Long live datasets.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/19/2005 3:06 PM Chris Platt

Interesting reading. I agree that there is a place and time for the dataset. After working with it extensively I agree on some points and disagree on others however with ADO.NET 2.0 Microsoft seems to have addressed some of the issues of performance, efficiency and flexibility especially with the Markee support for the data table. I think you'll find more people working with the DataSet/DataTable environment more and more.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/19/2005 7:06 PM Joe Brinkman

For those who would argue that datasets offer faster development than datareaders I would say that you ought to investigate the world of Code Generation. Using tools like CodeSmith or MyGeneration.net allows you to get all the speed benefits of datareaders and custom business objects while also providing you with similar development speed as datasets. If you go a little farther and invest some time learning an ORM tool like LLBLGen then you don't ever need to worry about the datareader/dataset argument again and can really focus on the real heart of your application the business logic and UI.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/20/2005 8:02 AM Eric

Performance is addressed between DataTables and DataSets, but not custom collections and either. I know it's dependent on how efficiently you code the custom collection, but I suspect that it would be tough to code up a collection that offers superior performance to a DataTable. First you have to retrieve the data in a table, then copy it over to the collection, pass it to the control and bind it. The extra step of copying it over, even if access during binding is very fast, gets huge for large data amounts. I deal with a reporting application that routinely passes tens of thousands of records to the Crystal Reports control to deal with and, although I have never done a full up test, suspect that it custom collections would not be fast enough.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/23/2005 1:40 AM Evgeny Alexandrovich

Actually, there is some pro and contras for both DataReaders and DataSets. Personally I think DataSet is convenient and should be used if not abused.

# DataTables are great, and about to get way better 5/24/2005 8:20 PM Mike Griffin

We offer an architecture called dOOdads, it's free as is MyGeneration, it's very fast as well. Anyway, see this


The DataTable as a First-Class Citizen
http://msdn.microsoft.com/msdnmag/issues/05/04/ADONET/default.aspx

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

The only way to go is O/R Mapping. I used Datasets, typed Datasets, DataReaders, etc, etc for over a year and they gave me nothing but headaches.

They do not encourage object-oriented design, and that should be reason enough.

Using NHibernate on my last project was so efficient and painless that I can't imagine going back.

# Very good read on the difference in the Dataset and Datareader 5/26/2005 6:08 PM Brian E. Cooper

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 5/30/2005 9:09 AM Ross Pace

I have to say that I really enjoyed this series of articles. Almost everywhere you go talks about databinding datasets to datagrids and the logic spreads to all other bindable objects.

Looking back on all my earlier programming I can see that most of my logic never needed a dataset. With the possible exception of trying to relate data from a very non-normalized DB (think a collection of spreadsheets stored in SQL Server) most data operations can be done with cleverly designed views and stored procedures.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 6/10/2005 5:42 AM Waqas Mahmood

Yeah... DataSets/DataTables are lovable objects. As they are prebuild in ado.net class lib. Yeah they have bundle of features which normally are not available in other dataaccess objects else where. but I have to say that in my last 2 years of .net development i hardly used datasets/datatables. reason is pretty simple... old style custom objects entities and collections didn't let me dip my fingers in that code.

I personally agree to those all folks around who practice this way as this way you get more control on your model and offcourse more value and performance gain.

even on win apps i preffer to design the object model on custom objects rather than using ds/dt.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 6/11/2005 4:10 PM Joe Chung

Re: custom object model vs. DataSet/DataTables, why not do both?

You could implement a custom object model using DataSets/DataTables as the underlying fundamental data store, instead of loading all the data into a DataSet and then copying it over to another internal data structure.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 6/16/2005 8:14 AM Carlton

What is wrong with using DataSets for unit testing? I only use the DataSet to ferry data to the database from my custom objects and out of the database to my custom objects. I assign a command instead of allowing the DataSet to generate the SQL for me.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 6/27/2005 4:45 PM Philip Nelson

I wrote about this some time ago and while many of the conclusions have been covered here not all of them have been. First the blog entry. http://blogs.xcskiwinn.org/panmanphil/archive/2004/09/21/281.aspx

Unless you have very good controls on your datareader lifecycle, the time a database connection is open, with all it's associated locks, will usually be *shortest* with a dataset: it uses the datareader itself after all. A middle tier is *much* easer to scale out than a database and with databases of any size, locking and cpu problems in the database will trump almost any middle tier problem you will ever have.

Of course pulling really large sets of data is a problem, but this is true even with a stream interface when the connection must be open for long periods of time.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 6/28/2005 2:12 PM Maurice

Scott, your August 2003 article,"Creating a Pageable, Sortable Datagrid" is a good example of when a dataset is necessary.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 6/29/2005 11:22 AM Sean

I understand all the above, but I am confused on how to deal with Parent-Child relationships in a DataReader. Can I do this, or is there some other way of doing the relationship thing?

I have data I want to return that has a relationship and the dataset keep causing IIS on my PC to declare an error with memory.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 7/8/2005 4:55 AM Phil Short

Apologies in advance, and nothing meant by this comment whatsoever ... but I couldn't help smiling at the juxtaposition of this blog entry with "I'm No Longer Cutting Edge". ;)

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 10/13/2005 11:55 AM George Jay

I've virtually eliminated DataSets from my architecture. Here is how my architecture populates a DataGrid containing customers named 'Smith'.

Suppose the client says, get me a list of customers whose last name is smith. Associated to my web DataGrid is a controller (think MVC) that is assigned to my DataGrid's DataSource. The controller inherts CollectionBase and implements IComponent, as well as all of the methods of the Business Domain object "Customer".

To setup and populate the grid on the webpage, I say:

CustomerController.GetByName("Smith");
CustomerGrid.DataBind();

That's it, there are no more lines, just two!

CustomerController constructs a Business object and says:

CustomerObject.GetByName("Smith");

This method calls the Data Tier, which says:

CustomerData.GetByName("Smith");

The Data Tier object method says:

Select * from customer where lastname=%1 order by LastName,FirstName

"Smith" gets subtituted for LastName.

I then use a DataReader to create an array of entities, which are subsequently fed into a Factory to produce a list of objects which become associated to CustomerObject. The controller has access to them (because it constructed the object).

I could use a DataSet and transport that between my layers, then use a Dataset to populate the DataGrid, but you know what ... if I can populate a DataGrid with two lines of code, guess what I'm going to do? The fact that it is super fast is a bonus, but I do this because it is easier. But further, because I'm using a five tier architecture, I can replace my database and data tiers without ever affecting my web application.

Regards,
George

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 10/19/2005 10:39 AM stardawg

OK...some good arguments on both sides. I have never seen a performance comparison between custom bo/collection classes vs dataset. Personally, I use Fowler's Data Gateway Pattern with a single dataset to return all of my datatables needed in my aspx page (and I create a composite gateway so I only make 1 conn to db to populate all of my tables). Then all I have to do is cache the dataset and my performance goes thru the roof vs datareader.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 11/1/2005 8:17 AM Siggy

So how do you do paging with DataReaders?

At http://aspnet.4guysfromrolla.com/articles/051805-1.aspx
you mention that paging can be done using DataReaders and direct readers to part15 of the DataGrid articles at: http://aspnet.4guysfromrolla.com/articles/070903-1.aspx

However, this article seems to achieve paging by using a DataSet!?!?

Siggy

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 11/3/2005 7:50 AM Vinla

With regards to DataSets and WebServices. How about getting the data into a DS, getting the XML, running that though an XSLT. Produce clean XML without schema info etc and sending that as the result? This could even perform some basic OR mapping. You could also have classes that can deserialze from this cleaner output. Maybe not the fastest, but you can then separate the DB representation from the OO representation. You can also change the mappings (or provide new mappings etc.) without recompiling code. In fact you can then control output with stored procs and XSLTs.

# More On Why I Don't Use DataSets in My ASP.NET Applications 11/29/2005 10:50 PM Alok

A critical choice when designing your application is whether to use a DataSet or a DataReader to retrieve data. If you need to retrieve many records rapidly,use a DataReader.In addition, retrieving results with a DataReader requires significantly less memory than a creating a DataSet. The DataReader does not allow random fetching, nor does it allow for updating the data.The DataReader object is fast, returning a read-only data from the server.

In contrast, the DataSet object is a cached data in disconnected manner stored in memory on the client. In effect, it is a small database in itself. Because the DataSet contains all of the data that has been retrieved, you have more options in the way you can process the data. You can randomly choose records from within the DataSet and update/insert/delete records at using DataAdapter. You can also manipulate relational data as XML. This provides impressive functionality for any application, but comes with a high cost in memory consumption.The DataSet maintains both the original and the changed data, which leads to even higher memory usage. Do not use DataSets with very large result sets as the scalability of the application will be drastically reduced

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 3/21/2006 11:24 PM Abhijeet

Hi Scott,

I am not against any of the record accessing methods, but I have noticed a typical problem in both the methods as such, while retriving rows from MS Excel sheet. I tried using .Fill method but if your column has Single digit Alphanumeric values, it reads only Numeric, treating the column as Double type. Any comments?

Cheers!
--
Abhijeet.

# re: More On Why I Don't Use DataSets in My ASP.NET Applications 2/22/2007 3:42 PM James C.

Hey siggy you asked "So how do you do paging with DataReaders?" I saw the definitive article on this and it's been on DNJ for a while so this ain't new - Dynamic DataGrid Paging and Sorting Using A DataReader - http://www.dotnetjunkies.com/Article/3F9C7FED-BFDB-49CC-BAF9-442079430EB2.dcik. - JC

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