In this chapter, we take a look at the ADO architecture; in the first section, "An Overview of the ADO Architecture," I describe how all of the pieces of ADO fit together to perform all of the functions that are necessary when accessing data sources. The remainder of the chapter is dedicated to the introduction and brief description of each of the key components of the ADO architecture.
ADO is built upon layer after layer of solid, proven technologies that allow applications to communicate with data, regardless of where it resides or how it is structured, using any language or scripting language. How can one technology offer techniques to access both relational databases and nonrelational sources such as email?
ADO is the lowest common denominator when it comes to data access. It makes no assumptions when it comes to its data sources. Because ADO cannot assume that the data source being accessed is even a database, it must use objects, methods, and properties that are relevant to all data sources.
With ADO, the data provider (as described in the previous chapter, the connection between the data consumer, or application), not the data consumer, creates the driver for a data source. What this means is that the version of ADO does not dictate the data sources that are available to us; rather, it dictates the functionality that is passed through from the data provider to our software. The burden is on the data provider or vendor to create and distribute the proper resources necessary to develop with their product. ADO is a framework; the behavior of the OLE DB providers can vary widely. ADO does not require that all interfaces and functionality be offered by each provider.
By designing the architecture of ADO as a simple generic interface, ADO is not tied to a specific command type, but is capable of growing with the needs and the abilities of both developers and data sources.
A powerful feature of ADO is its ability to offer the functionality of a particular data source. If your data provider supports stored procedures, for example, then you can use them.
ADO has already proven to be a very well-thought-out interface for data access, which is worth its weight in gold because it is so very robust and scalable, in addition to being so easy to use.
In the second half of this chapter, I will take a closer look at how each of the major components of the ADO architecture fit together to achieve its desired goal of a generic data-access interface.
ADO Versus DAO and RDO
DAO assumes that it's working with a Jet engine and an Access database. RDO also makes an assumption -- specifically, that it is working with an ODBC data source. With DAO, a Database object is used to connect to a particular database. The type of database must be picked from a list that is stored in the version of DAO that you are using to develop your application. If a database is not included in the current list, you are out of luck -- you cannot access that database with the version of DAO that you have. ADO has been designed to work with any data source, regardless of version. As long as an OLE DB provider driver is available, you can access that data.
The problem with DAO is that it is too tightly bound to the Microsoft Jet engine. The problem with RDO is that it is too tightly bound to the ODBC API. In contrast, ADO is fitted loosely around the concept of data access and the assumption that all data can be visualized as collections of fields that constitute records. ADO's approach to data-access interfaces allows it to remain up to date with new types of data structures and data-access techniques. If a new type of data query is later invented, as long as a particular OLE DB data provider supports it, ADO can take advantage of it through the use of a Command object.
To summarize, ADO has a smaller object model than DAO because it has been generalized to allow easy access to any data source, not just Jet databases or ODBC data sources. Its architecture is very similar to that of DAO, but it simplifies data access more than DAO or RDO did by using fewer objects. Because the same interface can be used to access any type of data source, ADO is easier to use.
No comments:
Post a Comment