ADO+ is an evolution of the ADO data access model that directly answers user requirements for developing scalable applications. It was architected for the web with scalability, statelessness, and XML in mind.
<P>
ADO+ has some of the same objects from ADO (like Connection and Command), and introduces new objects: DataSets, DataReaders and DatasetCommands.
<p>
One of the new concepts is the XML based DataSet. This object provides a consistent programming model around flat, relational and hierarchical data. It does this by having no knowledge of the source of its data and by representing the data that it holds as collections and data types. No matter what the source of the data within the dataset is, it is manipulated through the same set of standard APIs exposed though the DataSet and its subordinate objects.
<P>While the DataSet has no knowledge of the source of its data, the managed provider has detailed and specific information. The role of the managed provider is to connect, fill, and persist the DataSet to and from data stores. The ADO and SQL Server managed providers that are part of the NGWS frameworks provide three basic objects: Commands, Connections and DataSetCommands.
In the remaining sections of this document, weÆll walk through each of the parts of the DataSet and the ADO/SQL Managed providers explaining what they are, and how to program against them.
<p>
The important distinction between this evolved stage of ADO+ and previous data architectures is that there exists an object--the DataSet--that is separate and distinct from any data stores. Because of that, we can use the dataset as standalone entity. You can think of the Dataset as an always disconnected recordset that knows nothing about where the data came from, or where it is going.
Inside a DataSet, much like a database, there are tables/columns, relationships, constraints, views etc.
A DataSetCommand is the object that connects to the database to fill the DataSet. Later it connects to the database to update the data.
Getting the Data
In the past, data processing has been primarily connection based. Now, in an effort to make multi-tiered apps more efficient, data processing is turning to a message based approach that revolves around chunks of information. At the center of this approach is the DatasetCommand, which provides a bridge to retrieve and save data between a Dataset and its source data store. It accomplishes this by requests to the appropriate SQL commands against the data store.
<p>
The following sections will introduce you to some objects that have evolved, and some that are new. These objects are:
<ul>
<li><b>Connections</b>.
For connection to and managing transactions against a database.
<li><b>Commands</b>.
For issuing SQL Commands against a database
<li><b>DataReaders</b>. For reading data readonly off a stream
<li><b>Datasets and DatasetCommands</b>. For pushing data into a dataset, and reconciling data against a database. For storing, remoting and programming against flat data, xml data and relational data
</ul>
Note: When dealing with connections to databases there are two different options: ADO and SQL. In these samples we will use the SQL libraries. These are written to talk directly to MS-SQL server. The ADO libraries are used to talk to any OLEDB provider (as it uses OLEDB underneath).
<p>
<a name="subhead2">
<span class="subhead">Connections</span>
<p>
Connections are used to talk to databases. Commands travel over connections and result sets are returned in the form of streams which can be read by DataReaders, or pushed into DataSet objects.
<p>
The example below shows how to create a connection. Connections can be opened explicity by calling the Open method on the connection, or will be opened implicilty when using a DatasetCommand.
Commands contain the information that is submitted to a database. A command can be a stored procedure call, an update statement, or a statement that returns results. You can also use input and output parameters and return values. The example below shows how to issue an insert statement against the Northwind database.<p>
DataReaders are somewhat synonymous with a read-only/forward-only cursor over data. The DataReader API supports regular (flat, rectangular data) as well as hierarchical data. You can use a DataReader after executing a command to a database. For example, if you wanted to simply show the results of a search list in a web page, a DataReader is very appropriate.
DataReaders are returned after executing a command. The syntax is different from a recordset.
<span class="subhead">DataSets and DatasetCommands</span>
<p>
<B>DataSets</B><BR>
At the higest level, you can think of a DataSet as an always disconnected Recordset on steroids. The DataSet object represents a cache of data, with database like behaviours. There exists tables, columns, relationships, contraints, and data.
However, though a DataSet can and does behave much like a database, it is important to know that DataSet objects do not talk to databases. This important distinction allows the developer to anticipate an always consistent programming model regardless of where the data came.
Data coming from a database, an XML file, from code, or user input can all be put into DataSet objects and converted into files, forms, or databases. As changes are made to the DataSet, they are tracked; much like tracking changes in a document. The DataSet can provide a message (GetChanges()) in the form of another DataSet that can be used by DatasetCommands (or other objects) to update sources of data like databases.
<P>
DataSets have many XML characteristics, including the ability to produce and consume XML Data and XML Schemas. XML Schemas can be used to describe schemas interchanged via WebServices. In fact, Datasets with schemas can be compiled for type safety and statement completion.
<P>
<B>DataSetCommands (ADO/SQL)</B><BR>
DataSets can move in and out of sources using an object with the IDataSetCommand interface. We provide both the ADODatasetCommand and the SQLDatasetCommand that implements this interface.
A DataSetCommand is much like a Command on steroids. While a command has one CommandText property, a CommandSet has four--to represent InsertCommand, SelectCommand, UpdateCommand and DeleteCommand. The DatasetCommand can generate these at run-time based upon a select statement. Additionally, a developer can specify them in code, for example, when using stored procedures.
<P>
<div class="code">
<br> SQLConnection MyConnection = new SQLConnection("server=localhost;uid=sa;pwd=;database=northwind");
<br> SQLDataSetCommmand MyDataSetCommand = new SQLDataSetCommand("select * from customers", MyConnection);
The records are appropriately mapped to the given commands accordingly.
<p>
The sample below illustrates loading a DataSetCommand via a select statement. Then it updates, deletes and adds some records within the DataSet. Finally it sends those updates to the database via the DatasetCommand.
The constructed DeleteCommand, InsertCommand and UpdateCOmmand are shown in the page. It also illustrates using multiple DataSetCommands to load multiple tables into the DataSet (Customers and Orders).
<li>ADO+ is the next evolution of ADO for the NGWS Framework.
<li>ADO+ was created with n-Tier, statelessness and XML in the forefront. Two new objects, DataSets and DataSetCommands are provided for these scenarios.
<li>ADO+ can be used to get data from a stream, or to store in a cache for updates.
<li>There is a lot more information about ADO+ in the documentation.
