Managed providers, a new type of data provider, are the only direct ADO.NET way to access data sources. Such providers wrap a data source and return data through Microsoft .NET classes. Managed providers share one vision of OLE DB but are specialized, optimized, and easy to use.
Whenever you issue commands to retrieve data, you interact with a managed provider. When I wrote this article, only the .NET Framework's beta 1 was available. Beta 1 contains only two managed providers: one for SQL Server 7.0 and later, and one for all OLE DB providers. Actually, only the SQL Server provider is a managed provider because it accesses data through SQL Server's internal API. OLE DB providers work through COM and reveal their output through COM objects. In .NET, working with COM objects has a certain amount of overhead because .NET has no native COM support. .NET objects aren't COM objects, and you need intermediate proxy classes to make them interact. So, using OLE DB providers can cause poorer performance. But currently, the only managed provider available is for SQL Server 7.0 and later. Architecturally speaking, managed providers follow the same OLE DB philosophy but return recordsets through native .NET objects.
The OLE DB managed provider is equivalent to the OLE DB provider for ODBC and is less efficient than the ODBC provider at accessing the same data source. The managed provider for OLE DB doesn't directly access the data source but instead passes through the OLE DB COM layer. This approach results in minimal overhead.
Figure A shows the architecture of a managed provider. According to the ADO.NET specification, a managed provider must be able to expose data through a dual interface: the IDataReader interface (a fast, forward-only, read-only cursor) and the DataSet object. These two interfaces match the two possible ways of walking through retrieved data in ADO.NET. At present, no documented software development kit (SDK) is available to write data-source-specific managed providers.
