DataSet or DataReader?

When I talk with working developers, the question I hear most often is: Which is the right approach? The answer depends on your problem domain. The DataReader is a forward-only fire hose for data. It is often the perfect solution for reporting on data in the database. But forcing a design to use it may involve writing your own DataSet-like container for data if you need to use the data after you read a single row.

The DataSet, on the other hand, is a great way to hold data from the database, but filling it comes with a performance penalty. If you need to manipulate your data and save it back to the database, the DataSet is really the only game in town. Using the DataSet to simply report on data (like on a Web page, for instance) usually is the wrong approach. I say "usually" because there are always exceptions to this rule.

Let's look at a specific domain problem: an e-commerce site. Assuming we have a large number of salable items, I would use DataReaders to show the user the products they are looking for and a DataSet for the shopping basket. When you list products by caching all the items in your catalog, you usually lose efficiency when the cache is too large. I usually like to let the database handle the caching of recently used items. It does a better job in most cases. But a smaller DataSet to contain the user's information and shopping basket could be cached in the Web session so that we can limit the number of database reads and writes. If the visitor never ends up buying anything, their shopping basket could simply disappear (and never get persisted) when his or her session dies.

Just remember this caveat: If you need it cached, use a DataSet; if you need it once, use a DataReader.

本文地址：http://com.8s8s.com/it/it34964.htm