.NET Data Providers

< BACK  NEXT >
[oR]

An application that uses ADO.NET to access data commonly relies on some .NET data provider, software able to access a particular source of data such as SQL Server. Figure 6-1 shows how clients, .NET data providers, and DBMSs fit together. The client, written as managed code running on the CLR, can use various .NET data providers to access stored data. Each .NET data provider is also written as managed code, but a data provider might also rely on software that doesn't use the .NET Framework to accomplish its task.

Figure 6-1. Applications using ADO.NET can rely on .NET data providers to access information.
graphics/06fig01.gif

A .NET data provider allows access to stored data, such as data in SQL Server or Oracle

The .NET Framework class library includes two .NET data providers:

  • SQL provider: Written completely as managed code, this .NET data provider can be used to access Microsoft's SQL Server DBMS 7.0 or later. Access to earlier versions of SQL Server requires using another provider option.

  • OLE DB provider: Traditional ADO applications rely on OLE DB providers for access to data, so several of these providers exist. The OLE DB .NET data provider implements a wrapper around an OLE DB provider, such as those for Oracle or older versions of SQL Server, that lets it be used by .NET Framework applications.

The .NET Framework provides various .NET data providers

A third option, called the ODBC provider, will also be made available, although it's not officially part of the first .NET Framework class library release. The Open Database Connectivity (ODBC) API is another of the many data access interfaces Microsoft has provided for Windows developers, and applications that use it rely on ODBC drivers to get at stored data. ODBC is even older than ADO, so many, many ODBC drivers exist. The ODBC .NET data provider provides a wrapper around an ODBC driver, allowing managed code to use it for accessing data.

It's conceivable that other .NET data providers, such as a native provider for Oracle, will appear in the future. Doing this would improve performance for clients accessing databases other than SQL Server, because crossing the boundary between managed and unmanaged code burns more cycles than staying completely within the managed environment. Also, it's worth pointing out that .NET Framework applications can still use the traditional ADO interface via the COM interoperability support described in Chapter 5.

.NET data providers built from managed code have the best performance

Each .NET data provider is implemented as a group of types. The primary types that implement the SQL provider are located in the System.Data.SqlClient namespace, while those that implement the OLE DB provider are in System.Data.OleDb. Regardless of which provider you choose, each one offers an analogous set of classes. Figure 6-2 shows the fundamental kinds of objects supported by any .NET data provider. They are as follows:

  • Connection: Allows establishing and releasing connections and can also be used to begin transactions.

  • Command: Allows storing and executing a command, such as a SQL query or stored procedure, and specifying parameters for that command.

  • DataReader: Provides direct, sequential, read-only access to data in a database.

  • DataAdapter: Built on a DataReader, this class creates and populates instances of the class DataSet. As described later in this chapter, DataSets allow more flexible access to data than is possible using just a DataReader.

Figure 6-2. A .NET data provider allows clients to access data either directly as rows or through a DataSet.
graphics/06fig02.gif

Each .NET data provider exposes the same core set of classes

With the exception of DataSet, these names are generic rather than actual class names defined in the .NET Framework class library. There is no DataReader class, for example. Instead, each .NET data provider implements its own version of these classes. The DataReader for the SQL .NET data provider, for example, is implemented by the SqlDataReader class, while that for the OLE DB .NET data provider is implemented by the OleDbDataReader class.

Using these four kinds of objects, a .NET data provider gives clients two options for accessing data. Both use Connections and Commands to interact with a DBMS, but they differ primarily in how a client can work with the result of a query. As Figure 6-2 shows, a client that needs only straightforward one-row-at-a-time access to a query's results can use a DataReader object to read those results. Clients with more complex requirements, such as accessing a query's result in an arbitrary order, filtering that result, combining the results of multiple queries, or sending those results across a network, can use a DataAdapter object to retrieve data wrapped in a DataSet. Each of these choices is described next.

Clients can access data through a DataReader or by using a DataSet

Does the .NET Framework Require SQL Server?

Obviously, the answer to this question is no. After all, the OLE DB .NET data provider explicitly supports Microsoft's OLE DB provider for Oracle, which means that .NET Framework applications aren't limited to SQL Server. Still, it's too much to expect Microsoft not to favor its own product. By initially providing a native .NET data provider only for SQL Server, Microsoft is effectively guaranteeing that using its product will give the best performance with .NET Framework applications. And the next release of SQL Server will allow running the CLR natively in the DBMS, much like products such as Oracle that host the Java virtual machine. I'd be surprised to see Oracle or IBM's DB2 add this kind of native CLR support, so going forward it's reasonable to expect that SQL Server will have even more of an edge for .NET Framework applications. As usual, Microsoft technologies work best with other Microsoft technologies. This is generally true for all vendors, but no one does it as consistently or as assertively as Microsoft.

Here's a related issue: Is it possible to write an ADO.NET application that's portable across different DBMSs? After all, one of the reasons for using a common interface such as ADO.NET is to access different vendors' DBMSs in a common way. Yet each .NET data provider implements some parts of this technology differently. For example, the SQL provider's DataReader class is called SqlDataReader, while the OLE DB provider's DataReader class is called OleDbDataReader. A client that explicitly creates and uses an instance of either of these classes will be wedded to just one .NET data provider.

Although it's easy to create a client that works with only one particular provider, there are enough similarities that it's still possible to write code that works across different providers. Both SqlDataReader and OleDbDataReader implement the IDataReader interface, for instance, so code that instantiates and accesses either of these classes purely through this interface will work with either. As usual, writing portable code takes some work, and some DBMS-specific features may be lost, but it can be done.

< BACK  NEXT >


Understanding. NET. A Tutorial and Analysis
Understanding .NET: A Tutorial and Analysis (Independent Technology Guides)
ISBN: 0201741628
EAN: 2147483647
Year: 2002
Pages: 60

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net