ADO
OLE DB provides binding for C and C++ programmers and programmers who use other languages that contain C-style function calls. Some languages such as VB and VBScript don't provide pointer data types (address variables). Hence, they can't use C-style binding, and they can't make direct calls to OLE DB.
To add to the confusion, Microsoft introduced another data-access object model: ADO. ADO takes the objects based in DAO and RDO and provides a much simpler object model than DAO and RDO (albeit with some redundant functionality as you can now perform an operation in more than one way). The object hierarchy in ADO is much flatter than that in DAO. ADO contains several built-in objects that simplify the task of accessing data from data stores.
Figure 6, page 32, shows the many paths that applications can take to connect to databases. For example, a VB programmer can use ADO to connect an application to an OLE DB provider. If the database doesn't support OLE DB, the application can connect through ODBC. A Visual C++ (VC++) programmer can use ADO or connect directly through OLE DB.
An Example in ADO
Let's take a look at a simple example that shows how ADO works. Listing 1, page 32, shows how you might use a typical Recordset object—the central object in ADO. The Recordset object represents a set of records (much like a table) and supports cursor types such as adOpenForwardOnly, adOpenKeyset, adOpenDynamic, and adOpenStatic. The cursor can be on either the server side (which is the default) or the client side.
To access a record, ADO needs to scan a Recordset sequentially. And to access multiple tables, you need to perform a JOIN query to return the results as a Recordset. Although the Recordset object supports disconnected data access, ADO is still designed primarily for connected data access. This connected mode of access ties up valuable resources on the server side. In addition, to transmit a Recordset, you must use COM marshalling. COM marshalling is the process of converting data types, and this conversion takes extra system resources.
Starting with ADO 2.1, Microsoft added XML support to the ADO object model, which lets you save a Recordset as an XML document. However, it wasn't until ADO 2.5 that some of the restrictions and limitations of XML support in ADO 2.1 (e.g., persisting of hierarchical Recordset objects) were lifted. Although ADO can read an XML document into a Recordset, it can read only a proprietary schema known as the Advanced Data TableGram (ADTG).
In its quest to have a disconnected data-access mechanism, Microsoft extended ADO and introduced Remote Data Services. RDS is modeled after ADO and lets a Recordset be transferred to a client (e.g., a Web browser) without needing a live connection. However, RDS, like ADO, uses COM marshalling to transfer Recordsets from the server to the client.
The .NET Era
When Microsoft began designing the .NET Framework, the company took the opportunity to redesign the data-access model. Rather than extending ADO further, Microsoft decided to design a new data-access framework—but kept the acronym. Microsoft designed ADO.NET based on its experience with its successful ADO object model. But ADO.NET addresses three important needs that ADO doesn't address: providing a disconnected data-access model, which is crucial to the Web environment; providing tight integration with XML; and providing seamless integration with the .NET Framework (e.g., compatibility with the base class library's type system).
ADO.NET architecture. Figure 7 shows the ADO.NET architecture. The Recordset object, which performs so many functions in ADO, is now missing. In place of the Recordset object, ADO.NET has several dedicated objects to perform specific tasks. Table 1 describes three of these dedicated objects: DataAdapter, DataReader, and DataSet.
.NET data providers. An essential component of ADO.NET, a .NET data provider implements ADO.NET's interfaces. For example, a .NET data provider would implement the DataReader object so that either your application or the DataSet object could use it.
A data provider contains four main objects: Connection, for connecting to a data source; Command, which executes commands against a data source; DataReader, which reads data from a data source in connected read-only and forward-only mode; and DataAdapter, which reads data from a data source and uses that data to fill the DataSet object.
Visual Studio .NET includes two .NET data providers. The SQL Server .NET data provider is for connecting to SQL Server 7.0 and later databases. This access method is most efficient if you're using SQL Server 7.0 and later because the SQL Server .NET data provider communicates directly with SQL Server through the Tabular Data Stream (TDS) protocol. The OLE DB .NET data provider is for connecting to nonSQL Server databases such as Oracle or IBM DB2. This data provider uses the OLE DB provider for the respective databases.
Prev. page
1
[2]
3
next page 
