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:
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
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.