This post originated from an RSS feed registered with .NET Buzz by Eric Wise. Original Post: Scott doesn't use datasets in ASP .NET Applications Feed Title: Eric Wise Feed URL: /error.htm?aspxerrorpath=/blogs/eric.wise/rss.aspx Feed Description: Business & .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Eric Wise Latest Posts From Eric Wise

Scott doesn't.  I do... sometimes.

I generally prefer business objects and collections thereof for a good chunk of my ASP .NET applications.  This is mostly because by extending business objects with properties, methods, and events I can gain a level of control that isn't possible with the dataset.  Using a datareader to populate these objects is fast and easy.

However... in the case where I am just displaying data, such as binding results to a combo box or showing a summary grid, I tend to use a datatable or dataset.  But why?

1. I don't want an open connection/datareader in my UI layer.  I believe in separation of code into logical layers which means that binding a datagrid directly to a datareader is a no-no.  Fetching a datatable/dataset from the database layer is fine though.
2. There is a reduction in the amount of code you have to write to populate and kick back a datatable rather than a dataset.  In fact, if you are calling a stored procedure, you can even tweak the fields passed back without editing the code in the datalayer, the datatable will populate all the results automatically.  In the business object/collection world you'll have to tweak the code in the stored procedure, the data layer, and then the UI.  With datatables you can eliminate a step.
3. Aggregates, joins, and sorting!  Much MUCH faster and more efficient to let SQL Server do this than to force your webserver to do this walking collections, etc.  Not to mention the added complexity of handling collections in collections in collections to represent joins in a business object.  Congratulations, you just added a ton of code complexity to determine when to populate the object and its joins or just populate the object.  People that use lazy-loading without thinking end up with hundreds of database calls for a single grid bind when they refer to properties that require a lazy load in the grid.
4. Is populating a collection of objects really that much more performant that populating a datatable?  I doubt it
5. Is it faster to bind a datatable or a collection of business objects?  Once again, I doubt the difference is worthwhile.

So there you have it.  I'm not against business objects/collections.  I freaking love them... however, if you're just displaying data, not using any business logic, then it is my opinion that you are far better off passing out a datatable/dataset than trying to do SQL Server tasks inside your business objects.

Perhaps Sahil or John Papa can supply statistics for #4 and #5.  I have little patience for such measurements.  =)