ADO.NET is the way forward for data access on the Windows platform. It provides a host of new features in tune with the Internet and XML-centric world in which we now program. To developers steeped in the grand traditions of working with Microsoft technology, the first reaction is "Here we go again, yet another data access technology and a new set of acronyms." Fortunately, the changes are a big step forward and form part of a comprehensive platform for rapid application development called .NET. Let's take a few steps back on our journey to see where we're coming from in ADO, before discussing the new features in ADO.NET.
Universal Data Access (UDA) was an umbrella-like term for the previous family of data access technologies on the Windows platform. The core of the technology was the OLEDB C++ COM interface and a friendly automation version that rides on top called ActiveX Data Objects (ADO). OLEDB focuses on tabular data and provides a consistent interface to a variety of data sources: relational databases, OLAP databases, spreadsheets, even comma-separated files.
Figure 1 shows a scenario in which a VB client is accessing data from an Exchange Server, an Access database, and an Excel spreadsheet, using ADO as an intermediary to the raw OLEDB interfaces of the OLEDB providers. A raw C++ client is also shown accessing data from SQL Server directly from the COM interfaces of the SQL Server OLEDB provider.
Figure 1 Universal data access through ADO/OLEDB.
ADO gained popularity due to its ease of use and a simple, loosely coupled object model, as highlighted in Figure 2. The work it does to simplify OLEDB is often taken for granted by those working with the Automation model. Figure 3 highlights just a few of the OLEDB objects and interfaces ADO consumes for the benefit of the programmer. You can definitely appreciate the work someone has to do to write an OLEDB provider.
Figure 2 Primary ADO object model.
Figure 3 ADO wrapping OLEDB.