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?
- 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.
- 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.
- 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.
- Is populating a collection of objects really that much more performant that populating a datatable? I doubt it... either way you're walking data and inserting records into an object.
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. =)
Update: Here's a link to some datareader vs datatable stats: http://www.devx.com/vb2themax/article/19887/1954
Shows that the datareader is far more performant as you add more and more data. One caveat here before people glance and freak out at the difference: As a commented above, I use the datatable to show summary, join, you know... special data. The article shows how performance degrades all the way up to 10,000 records... realistically you should never be displaying a client more than 100-200 over the web if not for performance purposes but just readability. It's just too much information for the average human to process easily. If you feel like you have to show 10,000 records I suggest an alternative solution involving lots of filters.