Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
.NET Data Providers
ADO.NET specifies a provider model that's separate from OLEDB and runs as managed code. Figure 4 shows how a managed client interacts with data sources through .NET Data Providers that hide the details of data access. The SQL Server .NET data provider provides a high-speed route to manipulating relational data, bypassing the OLEDB layer and using the raw Tabular Data Stream protocol. An OLEDB .NET Data Provider is available to present a managed view of OLEDB interfaces and connect with data sources that don't yet have a managed provider written for them. An ODBC .NET Data Provider is available as a separate download from the MSDN site; the two providers mentioned above are bundled with the .NET Framework.
){kind=link}
Figure 4 ADO.NET stack.
The .NET framework uses namespaces to organize the large collections of classes that reside in it. System.Data is the home for the bulk of the core interface and class definitions for ADO.NET. Figure 5 shows the key pieces of the namespace; interfaces are colored white and classes are colored blue.
){kind=link}
Figure 5 System.Data namespace object model.
A .NET data provider implements the interfaces to provide the necessary functionality to clients. The SQL Server .NET data provider puts its implementation classes in the System.Data.SqlClient namespace and appends the Sql prefix to its classes. The OLEDB .NET data provider lives in the System.Data.OleDb namespace and uses OleDb for its prefix. Figures 6 and 7 show the two provider's namespaces. There is also a System.Data.SqlTypes namespace that has managed types that fit to the SQL Server database type system and a System.Data.Common namespace that provides concrete classes that a provider developer can inherit from to simplify building a provider.
){kind=link}
){kind=link}
Figure 6 System.Data.SqlClient namespace object model.
Figure 7 System.Data.OleDb namespace object model.