What is ADO? - Providers and Drivers
(Page 6 of 12 )
It’s important to understand how OLE DB Providers relate to ODBC Drivers, especially because an OLE DB Provider exists for ODBC, which seems somehow confusing. Take a look at this diagram, which shows the difference between providers and drivers:
This distinctly shows the two layers. You can use OLE DB Providers to access data sources, including ODBC data sources. This allows OLE DB to access data for which there is an ODBC Driver, but no native OLE DB Provider (such as DAV or Directory Services). Note that the ODBC provider is deprecated, and although it will still work and is still supported, it may not be in the future. For example, no new changes will be made to the OLE DB Provider for ODBC, it is not supported from ADO.NET, and it will not be supported on 64-bit operating systems.
The essential distinction is that Providers are for OLE DB and Drivers are for ODBC. |
Windows Distributed interNet Application Architecture (Windows DNA)
DNA is the strategy that Microsoft is defining as the ideal way to write distributed, n-tier, client/server applications. One of the interesting things about this strategy is that it’s really just a set of ideas and suggestions, rather than a complex, locked-in solution. It’s not a new idea, but some really good tools now make creating this type of application relatively easy.
The basic premise is to partition your application into at least three tiers, illustrated in this diagram:
The first tier is the user interface tier—this is what the user sees, and could be a Web page or another type of application written in any language. The second tier is where the business rules or processes lie; these determine where the data comes from, what rules apply to the data, and how it should be returned to the user interface. The third tier is the data layer—the actual data source.
The great thing about DNA is that it aims to be language-independent; it all hinges around COM (COM+ in Windows 2000 and later). COM allows easy object creation and re-use. Any component that supports COM will fit into this picture, so you can write your application in ASP and JavaScript, Visual Basic, Visual C++, Delphi, or any language that supports COM. Likewise, your business components can be in any language, so you can program in your preferred environment; there’s no need to learn a new language.
In the preceding diagram, you can see that Internet Information Server (IIS) and Microsoft Transaction Server (MTS) are mentioned in the Business Processes tier. IIS supplies the connection from Web applications to components, which could be MTS components or standalone components (that is, components not managed by MTS). The great advantage of MTS is that it makes your middle tier very easy to manage; you can just create a component and install it in MTS. Once you’ve done that, it becomes available to all applications that can call components. You can access the components on remote machines using DCOM, MTS, or HTTP (with RDS). You also get the added advantage of transaction processing and easy scalability without having to program it yourself. The user interface can then be built in any language that supports COM.
ADO Availability The Microsoft Data Access Components (MDAC) are available as a separate download from the Microsoft Web site at http://www.microsoft.com/data. The file name is MDAC_TYPE.EXE.
If you’re unsure what version of ADO, or any of its components, you’ve got installed, download the Component Checker from http://www.microsoft.com/data/download.htm. This utility will give you a complete list of ADO DLLs and their version numbers. You can also use the Version property of the Connection object (see Chapter 3).
 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: New Features >>
More ASP.NET Articles
More By Apress Publishing
/ 15 
