DataSet Vs Custom Entities


Dear Readers, Apologize for not sharing anything with you since so long. As was bit busy with projects. (But as I told in my earlier posts as well, It’s good to be busy. Because during your busy time you will learn a lot, and needless to say once you get time you will have a lot to share!)
This week, We were discussing what to use for our new project for passing data from one layer to another layer. DataSet Or Entities.
I’m big fan of Entities and Generics. But thought to do some research on it, before concluding anything. And my research revealed that I’m (I know you as well) not only one who is searching on this topic. Lot of people shared their views on web. But I filtered out few links, which I liked most (along-with the Excerpt which is important to read from that link)  and thought to share with you! So, here you go
“The problem with DataSets is that they tend to be pretty memory hungry. They also get a bit difficult to manage as your application gets larger. When you need more complex solutions, the initial effort that you put into getting custom classes up and running can pay off with shorter development cycles if you do it right. “
Going with custom classes is certainly better in many ways.
i) easier to add logic
ii) business validation is easier. This is tougher when using DataSet
iii) if you are using DataSet, even when the number of rows returned are small, the whole dataset has to be constructed which is quite an overhead. Custom classes are more light-weight
“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. “
“Now, amazingly, this has sparked somewhat of a religious war between various parties within the project. Just to be clear – I prefer custom objects – partly for their simplicity and readability”
“I agree with you on custom objects, you will have more control and better performance.”

  • Memory consumption using Dataset = 290,436 (3.5 times larger than using Products class)
  • Memory consumption using array of objects = 140,028 (1.7 times larger than using Products class)
  • Memory consumption using Product class = 82,656 (BEST)

So, no matter how you turn it, strongly typed custom classes are your best bet in terms of memory consumption!
2) BIZ and DAL are written by people different from the presentation layer group, so they have different knowledge about the data structures
While DataSets are an easy way to return data, I think they are less than ideal for a couple of reasons. First, they add a lot of bloat to the returned XML payload since DataSets return not only the data they contain but also the data’s schema.
In my original article one of my main thrusts for not using DataSets was the performance disparity between DataSets and DataReaders. As I cited from A Speed Freak’s Guide to Retrieving Data in ADO.NET, when bringing in several hundred or thousands of records, a DataSet can take several seconds to be populated, where as a DataReader still boasts sub-second response times. Of course, these comparisons against several hundred to several thousand records are moot if you are working with a much smaller set of data, say just 10 to 50 records in total. For these smaller sized result sets, the DataSet will only cost you less than a second (although the DataReader still is, percentage-wise, much more efficient).
Benefit with Custom Entity Classes
– Take advantage of OO techniques such as inheritance and encapsulation
– You can add custom behavior
– Object-Relational Mapping
– Mapping Custom Collections
– Managing Relationships between two entities in Object oriented way
I would agree with Marc G. 100% – DataSets suck, especially in a WCF scenario (they add a lot of overhead for handling in-memory data manipulation) – don’t use those. They’re okay for beginners and two-tier desktop apps on a small-scale maybe – but I wouldn’t use them in a serious, professional app.


So, in summary, as per my understanding, performance, maintainability, and serialization point of view entities looks more promising than DataSet.
Few of my guidelines:
You should use DataSet when:
1. Project is small.
2. Only Single person is going to work on all layers.
3. Data size is small.
4. Application is not going to get changed in future. (Mainly Database structure).
5. You are not worried about Maintainability.
You should use Custom Entities when:
1. Project is big.
2. Different people will be working on different layers.
3. Data size is big.
4. Application is going to get changed in future. (Mainly Database structure).
5. You are worried about Maintainability.
6. If you love to follow OOPs concepts.
These all are my views, and they might look biased toward Entities. Because as i told earlier, I’m big fan of custom entities. But if you would like to use DataSet and have good reasons to use it. Don’t worry go for it!
Happy Coding! 🙂


  • Hi! I understand this is kind of off-topic however I needed to ask.
    Does managing a well-established website such as yours
    require a large amount of work? I am brand new to running a blog
    however I do write in my diary daily. I’d like to start a blog so I will be able to share my own experience and views online. Please let me know if you have any kind of ideas or tips for brand new aspiring blog owners. Thankyou!

  • Do you have a spam problem on this site; I also
    am a blogger, and I was curious about your situation; we have developed some nice practices and we are
    looking to swap methods with others, be sure to shoot me an email if interested.

    • Dear Abhilash,
      Thanks for noticing and notifying! It’s fixed now!
      Keep reading!

  • Thanks, that’s a big help. I’m converting from webforms to MVC, but I want to stay as close to the metal as possible in the DAL. I was headed for custom classes when the possibility of using my familiar buddies Datasets came up, so I knew I had to research it. Your article saved me a lot of time and uncertainty!

    • Thanks for the appreciation!
      Happy Coding! 🙂

  • So his is where I may disagree:
    4. Application is not going to get changed in future. (Mainly Database structure).
    5. You are not worried about Maintainability.
    I really like to return a datatable from the db, and then display it to the user.
    Lets say for Maintainability, the user requests a new column to be returned from the database. Using a custom object this requires a code change. I have to go into the app, and a new property, make sure it’s being set, and update the view to see the new column.
    Now lets say that the user requests a new column and I used a datatable. I update the stored procedure that returns the data, and the column magically appears on their screen without me having to change any code at all.

    • Yeap — But main thing is how many users you are targeting. Your idea works for small user base.

      • How would it be any different with one user or one billion users? In my example if I have decided to give the users a new field, code change required for a custom object, no code change required for a data table.

Comments are closed.