The first thing that happens when someone posts performance numbers is to question the method of benchmarking.  My test was an ad hoc benchmark on my own workstation to get a feel for the performance difference, if any, between bringing aggregate data from a database using a DataSet and using a collection of domain objects.  Some have said that binding to collections of domain objects is a “heavy-handed” approach when all that is required is a read-only display of the data.  My opinion was that the DataSet, with its deep and complex object model, is slower(and more memory intensive) than using custom domain objects for this task. 

I created a read-only view of the customers table in the Northwind database.  I created a Customer object and CustomFactory for presenting an aggregate of Customer objects (one for each row).  I also created an object to return a DataSet with this same information.  I created two ASP.NET pages identical with a single DataGrid (with Viewstate off).  One bound the array of Customer objects, and one bound the DataSet.  Then I used Application Center Test to profile each page.  I made 2 runs each for 1 minute each. 

The page that used an array of custom domain objects to present a read-only display was 3.7% FASTER than the same functionality using a DataSet.  I'm not interested at all in the performance difference, but all I care to prove is that using custom domain objects is NOT a heavy-handed approach to displaying read-only aggregates of data.  Besides that, it makes for a better application design with cohesive logic.

I prefer to use custom objects for just about everything.  Yes, a DataSet does it all, but at the expense of everything else.  If I need a few rows from a table, let's take a look at all the objects I have to create just to get that:

• DataSet object
• DataTable object
• DataRowCollection
• DataColumnCollection
• DataRow object (for every row - this normally has a slightly bigger footprint than one of my custom objects)
• object for every field in every DataRow
• DataColumn object to define information about every column
• DataRelationCollection
• DataViewManager
• PropertyCollection
• ConstraintCollection

It seems to me that using a DataSet is a heavy-handed approach to moving data, but given that the performance difference is so small, my main reason for choosing custom domain objects is design.

My main motivation for posting about this was to disprove the misconception that using custom domain objects for read-only aggregate views is an overkill.  In fact, there is no proof of this performance difference by using the OO design.