2.3 Creating a Custom Data Provider

ADO.NET provides a set of interfaces that allow you to build a custom .NET data provider. While most DBMSs can be accessed through a specific .NET data provider or through the OLE DB .NET data provider, some reasons to implement a custom data provider include:

• To access proprietary data sources that have neither a specific .NET data provider nor an OLE DB provider that can be accessed through the .NET OLE DB data provider.

• To expose specific functionality of the data source that is accessed through a general-purpose provider. For example, a database that is accessed through the OLE DB .NET data provider might have functionality that isn't available through that provider. A custom data provider can be written to expose the database-specific functionality.

• To provide application-specific data access architecture to improve performance, simplify programming, and improve maintainability.

An alternative to writing a custom data provider for a proprietary data source is to write an OLE DB provider for the data source and use the OLE DB .NET data provider to access the data through that OLE DB provider. This approach might make sense in situations when broad access to a full set of database features is required. Once the OLE DB provider is written, the data source can also be accessed not only with the OLE DB .NET data provider but by any application or tool that supports OLE DB provider data access.

A custom .NET data provider must at least support the DataSet through the IDataAdapter interface, and possibly the IDataParameter interface for parameterized queries. Such a minimal data provider allows a DataSet to be loaded with data from the data source, the modification of data within the DataSet, and the reconciliation of the changed DataSet with the data source. A minimal provider can support clients that deal primarily with a disconnected data, thereby functioning as a bridge between the DataSet and data source.

A complete .NET data provider supports the minimum functionality described here, as well as connected data access using connections, commands, and transactions. A complete .NET data provider implements the complete set of IData* and IDb* interfaces.

When developing a custom provider, you must first identify the ADO.NET interfaces and classes that must be implemented to achieve the required functionality. Unsupported classes and methods should raise a NotSupportedException or a NotImplementedException as appropriate.

Table 2-2 describes the available ADO.NET interfaces.

Table 2-2. ADO.NET interfaces

Interface	Description
IDbConnection	A unique session that communicates with the data source.
IDbTransaction	A local transaction. This interface supports nested transactions, although providers aren't required to support them.
IDbCommand	Represents a query, stored procedure, or command against the data source.
IDataParameter	Exposes properties and methods required to define parameters for commands. Implementing this interface is optional for an IDataAdapter-only provider.
IDataParameterCollection	Allows a user to implement a parameter to a command and its mapping to DataSet columns.
IDataReader	A read-only, forward-only stream of data from the data source.
IDataAdapter	A DataAdapter that populates a DataSet and reconciles any changes to the DataSet back to the data source. This is the only interface required for every .NET data provider implementation.
IDbDataAdapter	A DataAdapter for use with a relational database that inherits from IDataAdapter. It populates a DataSet and reconciles any changes to the DataSet back to the data source. The .NET Framework also includes a utility class called DbDataAdapter that can be inherited along with IDbDataAdapter, which helps implement the IDbDataAdapter interface.

A custom adapter can provide access to data stored in a relational database. It is important to remember that there are no constraints as to how the ADO.NET disconnected classes are filled and how the changed data is updated back to the data source. Consider a solution other than developing a custom .NET data provider, if it is appropriate.

For more information about implementing a custom .NET data provider and about the interfaces described in Table 2-2, consult the .NET Development documentation at http://msdn.microsoft.com/library.