Choosing Data Containers for .NET, Part 1
- Inspiration for This Series of Articles
- What I Mean by "Data Containers"
- Best Practice for Data Containers
- .NET Options
- The DataReader: Background
- The Tests
- And the Testbed
- Result of the Tests
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In the dark ages before .NET, probably the most common choice for a data container was to use disconnected ADO Recordsets.
With .NET, the situation regarding data containers has changed. We can't really say that there is a clear best practice yet, but Microsoft most often recommends ADO.NET DataSets as the way to go. I, on the other hand, prefer to use custom classes and collections—that is, a custom object-oriented format. Who is right, Microsoft or me?
In this new series of articles, I discuss different data containers for .NET, including DataSet, the Generic container datatype, and custom classes. First up in this article is the DataReader (which isn't really a container, but it's discussed here as a baseline).
Inspiration for This Series of Articles
Early in 2002, I read the manuscript to Martin Fowler's book Patterns of Enterprise Application Architecture (Addison-Wesley, 2002). Fowler inspired me to reconsider the architecture I had discussed in my book .NET Enterprise Design with Visual Basic .NET and SQL Server 20001 (Sams, 2001). The architecture discussed in my book is pretty much DataSet-focused, but I started to think about using a domain model rich in functionality and built with custom classes. That was the main reason I started to write the series of articles for VB2TheMax, called "A Pure Object-Oriented Domain Model by a db-Guy." Very much related to the problem of constructing the domain model is determining what data containers to use. (The article you're reading right now stands alone from the VB2TheMax articles, so that is, of course, optional reading.)
The other source of inspiration that prompted me to write about data containers is that Microsoft has published some papers about architecture and best practices, and tends to recommend DataSets as the solution for most situations. One example of such an article is "Application Architecture for .NET: Designing Applications and Services," which states:
It is recommended that you avoid designs requiring you to transfer data in a custom object-oriented format, because doing so requires custom serialization implementation and can create a performance overhead. Generally, you should use a more data-centric format, such as a DataSet, to pass the data from the data access logic components to the business layers, and then use it to hydrate a custom business entity if you want to work with the data in an object-oriented fashion. In many cases, though, it will be simpler just to work with the business data in a DataSet.
This article starts investigating different options for data containers—regarding not only performance, but other factors as well—and tries to find pros and cons for different options.