Data Reader Characteristics

for RuBoard

As mentioned yesterday , data readers represent one of the two programming models exposed in ADO.NET that work with data (the other being the DataSet , which works with disconnected results). As a developer, you need to choose which programming model you're going to use for a particular scenario. To help you understand the differences and when a data reader might be appropriate, consider the following characteristics:

• Connectedness . Because the data reader exposes a connected and streamed model, unlike the DataSet , its uses are relegated to situations in which your application can maintain the connection to the data store while the data is being traversed. If you know, for example, that the data must be used offline, using a DataSet makes more sense because it can be persisted to a disk and doesn't require a continuous connection to the data store. That having been said, ideally , you should open a data reader and traverse it immediately to minimize the amount of time the connection is in use.

• Remoting . Unlike a DataSet , a data reader is derived from System.MarshalByRefObject rather than MarshalByValueComponent . This means that when using .NET Remoting, a data reader can't be passed between application domains by value but must be passed by reference. As a result, a data reader isn't serialized and passed between application domains. Instead, calls to the data reader are passed between domains. If a data reader is used in a remote application data reader and will result in cross-application domain communication each time a method or property of the data reader is accessed. Obviously, this is a situation you want to avoid in physically distributed applications. This architecture makes sense for data readers because the data reader holds on to a connection to a data store. Therefore, if you pass a data reader by value, you would also need to pass the connection object it is using, which would be problematic to say the leastdomain, the domain in which it was created will always host the. Figure 11.1 highlights this architecture by showing how a client application domain would access a data reader created in a separate application domain.

  Figure 11.1. Data reader architecture. In this diagram, the data reader ( dr ) is created on the server. When a method such as Read is called, the method is executed on the server and the results are passed to the client.

  

  Although data readers can be accessed by remote application domains, as shown in Figure 11.1, because of the number of calls this would generate between those domains, it's recommended that you use data readers only from within the domain in which they were created. In other words, code that creates a data reader should live in the same application domains (and therefore the same operating system process) as the code that consumes it.

• Data Sources. Data readers get their data from a connection object and so, typically, return data from only a single data store. In other words, you can't access data from both a SQL Server database and an Oracle database from the same data reader object. This can be done, however, with a DataSet , whose DataTable objects can contain data from anywhere because the DataSet neither tracks nor cares about the source of its data. For this reason, with respect to data sources, the DataSet is said to be heterogeneous, whereas the data reader is homogenous.

• Updateability . The nature of a data reader is that it provides forward-only, read-only, streamed access data. This means that the data isn't updateable. If you wanted to update data retrieved with a data reader, you would need to store it yourself in variables , for example, and later update the data store, perhaps using a command object and the ExecuteNonQuery method. A DataSet provides updateability by tracking the changes made to rows within its tables.

• Strong-Typing . As you learned on Day 6, "Building Strongly Typed DataSet Classes," a DataSet object can be strongly typed using the code generator utility accessible through VS .NET or the XSD.exe command-line utility. A strongly typed DataSet allows access to the data in an easier fashion because it derives from DataSet and exposes specific properties that map to the tables, rows, and columns of the DataSet . A data reader has no such equivalent, so you always access columns in a DataSet using a collection syntax with the name of the column or its ordinal.

But Are They Strongly Typed?

Unfortunately, Microsoft chose the term strongly typed to refer to a derived DataSet that exposes specific properties. As you'll see, the data reader also allows access to data in a strongly typed fashion in the normal sense of the term, meaning that the actual data is returned as the type it maps to in the database rather than as a generic type such as System.Object . Perhaps a better term for a strongly typed DataSet would be derived DataSet or mapped DataSet .

However, this text uses the Microsoft term to avoid any confusion when you read the online documentation.

• Data Manipulation . Because a data reader returns data in a streamed fashion, there is no opportunity to sort or filter the data after the ExecuteReader method has been called. As a result, you need to make sure that the statement that executes on the data store uses the appropriate ORDER BY and WHERE clauses (in the case of a relational database) if the order the rows are returned is important. However, using a DataView , the tables of a DataSet can be filtered and sorted in different ways at different times without having to execute another statement against the data store.

• Performance . Because a data reader accesses only a single row at a time, it's very efficient in terms of the memory consumed on the client. This results in the best performance possible for accessing data. However, it should be noted that internally a data adapter will use a data reader to populate a DataSet when its Fill method is called, so the cost of using a DataSet from the server's perspective isn't any greater than using a data reader. The difference lies in the fact that when a DataSet is used, the DataSet must first be populated before the data is accessed, so you don't get direct access to the data as with a data reader. A second consideration is that if a multi- user application such as an ASP.NET Web site uses DataSet s, the users will be consuming more resources than they might if data readers were employed. This incremental cost, when totaled over hundreds or thousands of users, can put an extra burden on the Web server. However, because of the disconnected nature of DataSet objects, they can be cached unlike data readers, thereby reducing the number of times the data store needs to be accessed.

Table 11.1 summarizes the differences between the DataSet and data readers.

Table 11.1. Data readers versus DataSet . This table summarizes the differences you should consider when deciding which programming model to use.

DataSet	Data Reader
Can be used without a connection	Requires a continuous connection to the data store
Serializable across application domains	Used by reference across application domains
Stores heterogeneous data	Provides access to data from a single source
Is updateable and uses a data adapter for updates	Read-only; must roll your own method to update
Can be strongly typed	No property access to columns returned
Can be sorted and filtered	Rows can't be retrieved in an arbitrary order or filtered
Performs well but consumes resources on	No resource consumption on the middle tier the middle tier

for RuBoard