Data Access Technology Evolution
Release Date: 4/1/2004
| Update Date: 4/1/2004
Wei-meng lee
In the early days of the database, developers only need to know a detailed knowledge of database products being used. But database products and technologies have developed very quickly. From a relational database to a non-relational data store (such as email and file system), data access technology must always follow the rapid changes in technology. And, with the emergence of the client / server and multi-layer application structure, the developer must now understand a variety of data access technology. Most developers have spent several years of learning to learn many techniques, such as ODBC, DAO, RDO, OLE DB, ADO, and RDS. Now Microsoft has launched the .NET framework, and, there is another new data access technology: ADO.NET.
When we are immersed in every new technological advancement, we often ignore how data access technology evolves, and the reasons for each technology emerged. Understand the progress of these technologies; from ODBC to ADO.NET £; help to select appropriate techniques for their organizations and optimize them.
ODBC
In the most basic database design type, the application relies only one database. In such a simple setting, application developers can program directly for the interface of the database system. Although this method provides a fast and effective data access method, it is often a big problem that hinders development when developers need to extend the application. The method of single database also means that each existing application must have different versions to support each database. As the business changes, development and merge, the application must access a variety of databases running on different platforms.
ODBC technology provides a common interface for accessing the heterogeneous SQL database. ODBC uses SQL as a standard for accessing data. Page 30 of Figure 1 shows a relationship diagram of a standard ODBC structure. This interface provides maximum interoperability: an application can access different SQL Database Management System (DBMS) through a common set of code. Therefore, developers can build and distribute client / server applications without a specific DBMS.
Developers can add database drivers to link applications to DBMs selected by users. As shown in Figure 1, the driver manager provides an intermediate link between the application and the database. The ODBC interface contains a series of functions, implemented by each DBMS driver. When the application changes its DBMS, developers use only new DBMS drivers to replace the old drivers, and the application can run £ as usual; no modification of the code.
DAO and RDO
ODBC uses a low-level interface, so C and C programmers are people who really benefit from ODBC technology. The Visual Basic (VB) programmer does not have a simple way to access the ODBC interface. Prior to VB 6.0, developers had to rely on a higher level of data access mode. Page 30 of Figure 2 shows how VB programmers use Data Access Objects (DAO) to access the database.
DAO is based on the database engine based on Microsoft Jet £ ¨ Microsoft Access. Jet is the first object-oriented interface that is connected to Access. Using Access Applications You can use DAO to access the database directly. Since DAO is modeled in strict accordance with Access, using DAO is the fastest and most effective way to connect the Access database. DAO can also be connected to a non-Access database, such as SQL Server and Oracle. DAO uses ODBC, but since DAO is specifically designed to be dialogue with Jet Engine, JET will explain the call between DAO and ODBC. This additional explanation step causes a slower connection speed when using a database other than Access. To overcome such a limit, Microsoft created RDO. Page 30 of Figure 3 shows how RDO directly accesss the ODBC API without having to pass the JET engine. Soon, Microsoft launched ODBCDirect, which is an extension of DAO, using RDO in the background. Figure 30 Figure 4 shows how OdbcDirect allows existing DAO applications to access the database without the performance loss of the Jet engine.
OLE DB
ODBC has become a standard for accessing the client / server database for many years. The ODBC provides a standard interface, the interface requires the SQL processing function, and is optimized for SQL-based approaches. However, what happens if you want to access a non-relational data source that does not use SQL (for example, the data that stores data in Microsoft Exchange Server in relationships, what is the situation?
Enter OLE DB. OLE DB is built over ODBC and extending this technology to provide a component structure that provides a higher level data access interface. This structure provides consistent access to SQL, non-SQL, and non-structured data sources on the enterprise and Internet. (In fact, when the SQL-based data is accessed, OLE DB still uses ODBC because it is an optimal structure for SQL.) As shown in Figure 5 on page 32, OLE DB consists of three components: data user ( For example, an application); a data provider containing and disclosing data, and a service component (eg, query processor, cursor engine) that processes and transmits data. OLE DB is an API that operates for SQL data sources and non-SQL data sources (eg, emails and directories).
ADO
OLE DB provides bindings for C and C programmers and programs that use other C style functions call languages. There are some languages (such as VB and VBScript), do not provide pointer data types (address variables). Therefore, these languages cannot be bound to C style and cannot call OLE DB directly.
On this basis, Microsoft launched another data access object model: ADO. The ADO uses DAO and RDO-based objects and provides a simpler object model than DAO and RDO (although some redundant functions can be generated, more than one method can be used when performing an operation). The object hierarchy in the ADO is more gentlink than the DAO. The ADO contains a built-in object that simplifies access tasks for data storage area data.
Figure 6 on page 32 shows a number of ways to connect to the database. For example, VB programmers can connect an application to an OLE DB provider using ADO. If the database does not support OLE DB, the application can connect via an ODBC. Visual C (VC ) programmers can use ADO or directly to OLE DB. Example of ADO
Let's look at a simple example, it shows how the ADO is running. Listing 1 on page 32 shows how you can use a typical record set object £; ADO's core object. The record set object represents a series of records (very similar to a table) and supports cursor types, such as AdopenForwardonly, AdoPENDYNAMIC, and AdOpenStatic. Cursors can be on the server side (by default) or on the client.
To access a record, ADO needs to scan records in sequence. To access multiple tables, you need to execute the Join query and return the result as a recordset. Although the record set object supports disconnection data access, ADO is mainly designed for connection data. This connection to the access mode takes up important resources of the server. In addition, to transfer the record set, you must use COM package processing. COM seal processing is a data type conversion process that takes up additional system resources.
Starting with ADO 2.1, Microsoft adds XML support to the ADO object model, so that the record set can be saved as an XML document. However, until ADO 2.5 appears, some restrictions supported by XML in ADO 2.1 (for example, the maintenance of the hierarchical record object) is canceled. Although ADO can read an XML document into a recordset, it can only read a dedicated architecture named Advanced Data TableGram, ADTG.
Microsoft wants to have a disconnected data access mechanism that extends ADO and introduces Remote Data Services (RDS). RDS is modeled according to ADO, and the recordset can be transferred to the client (for example, a web browser) without real-time connection. However, like ADO, RDS uses COM package processing to transfer records from the server to the client.
.NET era
When the design .NET framework is started, Microsoft has redesigned the data access model as an opportunity. Microsoft did not further expand ADO, but decided to design a new data access framework; but retained the abbreviation. Microsoft designed ADO.NET based on its successful ADO object model. However, ADO.NET meets the three important needs of ADO unable to meet: provides a disconnected data access model, which is critical to the web environment; providing tight integration with XML; also provides seamless with .NET framework Integration (for example, a compatible base library type system).
ADO.NET structure. Figure 7 shows the structure of ADO.NET. However, it is lacking record set objects that can perform many functions in ADO. ADO.NET has several dedicated objects to perform specific tasks for replacement of records. Table 1 describes three special objects therein: DataAPter, DataReader and DataSet.
.NET data provider. The .NET data provider implements an ADO.NET interface, which is a basic component of ADO.NET. For example, a .NET data provider implements a DataReader object so that applications and dataset objects can use it.
A data provider contains four main objects: Connection objects, used to connect data sources; Command objects, execute commands for data source; DataReader objects, read data from data source in connection mode; DataAdapter object , Read data from the data source and populate the data set object using the data read. Visual Studio .NET includes two .NET data providers. SQL Server .NET Data Provider is used to connect to SQL Server 7.0 and higher databases. This access method is very effective if you use SQL Server 7.0 and later, because SQL Server .NET Data Provo is directly communicated directly with SQL Server through the Table Data Flow (TDS) protocol. OLE DB .NET data provider is used to connect non-SQL Server databases such as Oracle or IBM DB2. This data provider uses the OLE DB provider for the corresponding database.
When writing this article, Microsoft has just released the RELESE CANDIDATE BETA version of the third data provider for .NET .Net Data Provider. You can download the data provider from the Microsoft site in http://www.microsoft.com / data / download_odbnetrc.htm.
Figure 8 shows various ways to connect to the application through the ADO.NET connection database. When choosing a path, the factor to consider is the problem that should be used .NET data provider. If you are using SQL Server 7.0 or higher, select SQL Server .NET data provider is reasonable. If the database is a non-SQL Server database (for example, Oracle) that comes with the SQL Server 6.5 or any OLE DB, you should use the OLE DB .NET data provider. Note that even use SQL Server 7.0 or higher, you can still use the OLE DB .NET data provider, but will lose performance advantages when communicating directly through TDS and SQL Server. However, the advantage of this non-specific approach is that the portability is £; there is no need to modify the code to exchange data in the database used.
Second, determine the tasks that need to be executed. DataReader objects may be enough if you only need to read and display data from the data source. However, if you need to operate data (you may need to perform some editing and deletion), a dataset object should be used. The data set is only used when needed, because the dataset itself is slower than DataReader. (The data set uses DataReader to fill it.)
Example in ADO.NET
Let's take a look at the ADO.NET in the web service. Listing 2 shows a web service that returns a dataset object. The code in Listing 2 is similar to the code in Listing 1. The web service in Listing 2 retrieves the Authors table from the PUBS database and discloses it as a web service. Web services use the SQL Server .NET data provider, as shown in the following namespace import line:
Imports system.data.sqlclient
First, the Web Services and SQL Server 2000 database establish a connection:
DIM CONN AS New SqlConnection ("Server = localhost; uid = sa; password =; database = pubs")
Then, the web service uses the Command object to perform a query on the database: DIM COMM AS New SQLCOMMAND (SQL, CONN)
Next, the web service populates the data set using the DataAdapter object:
DataAdapter.Fill (DS, "authors_table")
Note that the connection will turn off immediately after the population data set, and unlike the connection in ADO, you must open when the record set is traversed. The resulting data set is returned as a web service. Figure 9 shows a part of the data set acquired when performing a new web service. The data set and its architecture are represented in XML format. The client application can bind the dataset by using DataGrid. Listing 3 shows the code that performs this binding. Figure 10 shows the situation where the resulting data set is bound to the DataGrid control in the ASP.NET Web application, which displays the data set to the user more friendly format. ASP.NET provides a lot of server controls that automatically bind to the dataset.
Use ADO in .NET applications
Although ADO.NET has many powerful new features, you may wish to continue using ADO for various reasons. (For more information on whether to convert to ADO.NET or use ADO and ADO.NET, see page 37 of Dino Esposito's "A Soft Landing To ADO.NET".) If you are developing new. NET applications should choose ADO.NET. But if you are migrating applications, you may want to keep ADOs in existing projects and use ADO.NET to boot new projects. The .NET framework allows the use of ADOs in the .NET application via COM Interop, which provides backward compatibility without modifying the ADO. You need to import the ADO type library in the form of an assembly, as shown in Figure 11. Then, ADO can be used as sample code, as shown in Listing 4.
Make a wise choice
Data Access Technology is continuously developing. Another technology has already occurred even before a technology is mastered. Only one thing is determined: In application development, the database plays an increasingly important role. Understand the latest technology £; and the development of the development of this technology will help to choose the right technology for current work, and help to make a wise choice when the organization needs to change.
Error, evaluation, and advice | Law | Privacy | Advertising
Copyright 2002 Prenton Media, Inc. All rights reserved.
Go to the original English page
