Getting to Know ADO.NET - Beginning C# 2008 Databases: From Novice to Professional - page 186

Now that you've played with all the data providers that access SQL Server (the SQL
Server CE data provider is beyond the scope of this topic), let's make sure you clearly
understand what a data provider is and how different data providers can be used to
access data.
Data Providers Are APIs
The .NET Framework data providers, sophisticated as they are (and you'll learn plenty
about exploiting their sophistication later), are simply APIs for accessing data sources,
most often relational databases. (ADO.NET is essentially one big API of which data
providers are a major part.)
Newcomers to ADO.NET are often understandably confused by the Microsoft
documentation. They read about Connection , Command , DataReader , and other ADO.NET
objects, but they see no classes named Connection , Command , or DataReader in any of the
ADO.NET namespaces. The reason is that data provider classes implement interfaces in
the System.Data namespace. These interfaces define the data provider methods of the
ADO.NET API.
The key concept is simple. A data provider, such as System.Data.SqlClient , consists of
classes whose methods provide a uniform way of accessing a specific kind of data source.
In this chapter, you used three different data providers (SQL Server, OLE DB, and ODBC)
to access the same SSE database. The only real difference in the code was the connection
string. Except for choosing the appropriate data provider, the rest of the programming
was effectively the same. This is true of all ADO.NET facilities, whatever kind of data
source you need to access.
The SQL Server data provider is optimized to access SQL Server and can't be used for
any other DBMS. The OLE DB data provider can access any OLE DB data source—and
you used it without knowing anything about OLE DB (a major study in itself ). The ODBC
data provider lets you use an even older data access technology, again without knowing
anything about it. Working at such an abstract level enabled you to do a lot more, a lot
more quickly, than you could have otherwise.
ADO.NET is not only an efficient data access technology, but also an elegant one.
Data providers are only one aspect of it. The art of ADO.NET programming is founded
more on conceptualizing than on coding. First get a clear idea of what ADO.NET offers,
and then look for the right method in the right class to make the idea a reality.
Since conceptual clarity is so important, you can view (and refer to) connections,
commands, data readers, and other ADO.NET components primarily as abstractions
rather than merely objects used in database programs. If you concentrate on concepts,
learning when and how to use relevant objects and methods will be easy.