In much of my recent development work, I've been concentrating on ADO.NET and Visual Studio .NET as I try to get up to speed on the latest data-access technologies out of Redmond. In working with ADO.NET, I've found a lot to like—especially for Web development. The built-in disconnected model and data caching are naturals for building scalable Web applications. In addition, the new DataSet namespace has some behind-the-scenes features that can give you more control over server actions than you ever had by using disconnected ADO recordsets. However, the ADO.NET data-access framework is missing a few important components.
But first, the plus side. One of ADO.NET's coolest features is the System.Data.SqlClient namespace's direct use of SQL Server's native Tabular Data Stream (TDS) protocol to access SQL Server. Microsoft's tests of SQL Server database access through ADO.NET indicate that the SQL Server .NET Data Provider is the fastest SQL Server data-access mechanism available—thanks primarily to the efficiency of TDS. The ADO.NET DataSet namespace also provides some valuable development features. DataSet lets you specify your own stored procedures to be called when changes to the dataset are propagated back to the database. I'm also fond of the ability to use the For Each statement to iterate through datasets, a capability that lets you navigate through datasets like you would any other collection.
On the minus side, however, ADO.NET is missing a few components that you probably expect to be present. Perhaps the biggest single omission is the lack of the OLE DB Provider for ODBC, which lets your ADO applications connect to any ODBC-compliant data source without the need for a native OLE DB provider. Although ADO.NET provides the System.Data.OleDb namespace, out of the box, you'll find support for only the SQL Server SQLOLEDB Provider, the Oracle MSDAORA OLE DB Provider, and the Access Microsoft.Jet.OLEDB.40 OLE DB Provider. The MSDASQL OLE DB Provider for ODBC is disabled. But you can still provide this functionality by creating a COM Interop wrapper for ADO, then connecting to the database by using the older OLE DB Provider for ODBC supplied with ADO. You'll also find that ADO.NET doesn't provide a native .NET Data Provider for Oracle; you must make Oracle connections by using the System.Data.OleDb namespace.
Another piece missing from the ADO.NET framework is an equivalent namespace for the ADO MD object library. ADO MD is the data-access library for developing SQL Server 2000 Analysis Services (or SQL Server 7.0 OLAP Services) applications. Again, although no equivalent to ADO MD exists in the ADO.NET data-access framework, you can use the COM-based ADO MD object library from your .NET applications by creating your own COM Interop wrapper for the ADO MD object library. For the record, Microsoft has stated that it intends to develop native .NET Data Providers for ODBC, Oracle, ADO MD, and XML in a future release—probably the next release of SQL Server.
As you start to implement ADO.NET, remember that it's essentially a 1.0 release of a new technology. As such, it provides a host of valuable new functionality, but it's also missing some pieces of the more mature ADO technology that it replaces.