CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeffrey Palermo (.com)

Blog moved to www.jeffreypalermo.com

Displaying aggregates: DataSet vs. Domain object performance - level 300

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.



Comments

Jeffrey Palermo said:

I've never heard the performance argument. I would guess that "heavy handed" refers to the amount of code required, as opposed to performance.
What is the lines of code comparison for your 2 test code bases?
# May 20, 2005 11:21 AM

Jeffrey Palermo said:

The only difference is that I have to define a Customer class. Each example uses a factory class that is in charge of getting the actual data from the database. The only difference is that the DataSet factory object just fills a dataset, where the other one creates multiple instances of Customer.
# May 20, 2005 11:35 AM

Jeffrey Palermo said:

I had this same discussion the other day with someone. My arguements were almost identical to yours. I absolutely hate using datasets and will gladly code up a doomain class to manage data anyday of the week. I have a standard collection class that we use to go along with them. All we do is override a couple of methods and you have complete binding support to go with it.
# May 21, 2005 12:43 PM

Jeffrey Palermo said:

I agree with both Jay and yourself. I work with someone who coded a bunch of stuff using a dataset. unfortunatly, due to the complexity of the project we have to scrap all that code. Custom classes will make everything we needed done so much easier and cleaner.

Jay, what level have you been able to extend your databinding.
# May 22, 2005 12:14 PM

Chris Donnan said:

Well - here it is - Objects vs DataSets - Especially in a situation where you
are not accessing...
# November 13, 2005 5:26 PM

About Jeffrey Palermo

Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems in Austin, TX. Jeffrey specializes in Agile coaching and helps companies double the productivity of software teams. Jeffrey is an MCSD.Net , Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, AgileAustin board member, INETA speaker, INETA Membership Mentor, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate. Check out Devlicio.us!

Our Sponsors

Proudly Partnered With


This Blog

Syndication

News

Headspring Systems

View Jeffrey Palermo's profile on LinkedIn

See my new blog at .jeffreypalermo.com