What is ADO? - Why ADO?
(Page 4 of 12 )
OLE DB is a COM-based set of object-oriented interfaces, so it is too complex for a large portion of the programming community to use, or it is not suitable because they use programming languages that don’t have access to custom COM interfaces. For example, accessing OLE DB directly requires C++ because of the OLE DB interface’s complexity. ADO is the higher-level model that most people will use, because it allows access from dual-interface COM components that can be accessed from Visual Basic and scripting languages. It equates fairly well to the DAO level, where you create an object and call its methods and properties. As a COM component, it can be used from any language that supports COM, such as Visual Basic, VBA, scripting languages, and Visual C++.
So now my diagram looks even more enticing:
Various languages all have the ability to use a central data access strategy. Some languages (like Java and Visual C++) can talk directly to OLE DB in addition to talking to the easier ADO—although we’ll be looking at only the ADO layer here.
ADO also improves speed and ease of development by providing an object model that allows data to be retrieved from a data source with as little as one line of code.
ADO addresses another pressing need that has been created by the increasing use of the Web as an application medium. Conventional applications are generally connected to their data store via a Local Area Network (LAN). They can open a connection to the data and keep that connection open throughout the life of the program. Consequently, the data store knows who is connecting. Many applications also process data on the client—perhaps a set of records that the user is browsing through or updating. Because the client is connected to the server—the data source—there’s no trouble updating the data.
On the Web, however, the underlying HTTP protocol is stateless. No permanent connection between client and server exists If you think about the way the Web works, you’ll realize why this is a problem:
- You request a Web page in your browser.
- The Web server receives the request, runs any server-side script, then sends the page back to you, and the connection is closed.
That’s it. As soon as this is over, the Web server forgets about you. Admittedly, with ASP you can store some sort of session state, but it’s not very sophisticated. How then, with this disconnected network, do you provide a system that allows data to be updated on the client and sent back to the server? This is where ADO comes in, with disconnected recordsets. This technology allows the recordset to be disassociated from the server and reassociated at a later date. Additionally, you can update, insert, and delete records on the disconnected recordsets locally, and update the central set of records (the server) at a later date. In fact, disconnected recordsets don’t have to be associated with a database at all—they can be manually created and used as a data store in much the same way as collections are. Manually created recordsets, however, cannot be used to update data stores.
The use of client-side data manipulation also allows you to sort data, find records, and generally manage recordsets without resorting to additional trips to the server. Although this idea primarily fits with the nature of Web applications, it can work just as well for the standard type of applications running on a LAN, and can reduce network traffic.
 This is from ADO Programmer's Reference, by Dave Sussman (Apress, ISBN 1590593421). Check it out at your favorite bookstore today. Buy this book now. |
Next: ADO and ADO.NET >>
More ASP.NET Articles
More By Apress Publishing
/ 15 
