Choosing Data Containers for .NET, Part 2
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In the first installment of this series of articles, I discussed the DataReader. It's actually not what I call a data container, but it's a very good baseline for the tests because the other options use DataReader behind the scenes. In this second article, I discuss DataSets, both untyped and typed.
NOTE
Supplementing code for this article can be found at
http://www.jnsk.se/
informit/container1.htm.
Keep the Fire Burning
In the first article, I posed the question of whether Microsoft or I have determined the best data container for most situations. I vote for custom classes, and Microsoft seems to vote for DataSets. My friend J.C. Oberholzer sent me some feedback:
I tend to think you are right—Microsoft writes ADO.NET and updates it as they go along. If you combine different components, you may end up supporting different versions of ADO.NET and DataSets when Microsoft decides to upgrade ADO.NET for any one of their reasons. When working with multiple components to create a system and maintaining different versions of these components, I would rather maintain my own than rely on Microsoft to make the decisions. The DataSet has a lot of built-in functionality that this guy needs, some that another guy needs, and so on. My custom goodie has the functionality that I need and can debug.
That's an interesting viewpoint, in my opinion. To balance it a bit, though, I've also heard that because Microsoft is pushing DataSets so much, they will see to it that we have a smooth upgrade path in the future.
Okay, let's get started with the topic of today: DataSets. (But be sure to read the first article, if you haven't already!)