- UDA Revisited
- The ADO Object Model
- Enter ADO.NET
- .NET Data Providers
- Comparing ADO and ADO.NET
- The Future of ADO.NET
- What's Coming in This Series?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Comparing ADO and ADO.NET
The ADO.NET object model has similarities to ADO that may be comforting to the coder who is making the transition to the managed way of programming. The Connection and Command objects of ADO.NET in particular work similarly to their ADO counterparts. What accounts for a big paradigm shift is the way Microsoft factored the interfaces used to manipulate results sets from a provider and the lack of server-side cursor or result set manipulation.
The DataReader takes on the role of forward-only, read-only "firehouse" cursor Recordset in ADO.NET. It's designed for use in high-performance applications that don't need to pass data objects between application domain, process, or machine boundaries and want the least amount of resource use in pulling data from a source. The biggest limitation is the need for the Connection object to maintain its link to the data source while code is iterating through the rows of a DataReader. Another shortcoming is the inability to update row content with respect to the data source, which must be completed using execution of the Command object.
The DataSet takes on the disconnected cache capabilities of the Recordset while matching the hierarchical data manipulation capabilities of the ADO shape provider. The DataSet is a disconnected relational database in its own right, holding multiple tables of data along with a referential integrity mechanism to protect data and allow easy navigation of parent/child rows. The user can create the structure and data programmatically, using it as a data-carrying vehicle without ever connecting to a data source.
Along with its tabular features, the DataSet is unique in its ability to work with XML and marshal effortlessly across tiers. It can load and save its relational structure and data contents to XML documents using a flexible serialization mechanism. The serialization occurs with full fidelity using current XML standards such as XML Schema. It also uses the XML serialization to marshal-by-value across managed coding boundaries. The XML features make it the data vehicle of choice for building web services and other types of distributed applications.
The DataSet requires some help in loading and updating its information to a non–XML data source. The DataAdapter interface steps in to fill this void and answer the call as a replacement for the batch update functionality of the ADO Recordset. It works by aggregating the services of a collection of Command objects. The DataAdapter uses the SelectCommand to fill rows into a DataSet during the load process and uses the DataSet row state information and column values to execute the appropriate UpdateCommand, InsertCommand, or DeleteCommand during the update process. The nice thing about this design is the fact that the programmer has full control over the efficiency of data manipulation commands executed when working with a DataSet.