Pro ASP.NET 2.0 In CSharp 2005 (2005) [eng]

230 C H A P T E R 7 ■ A D O. N E T F U N D A M E N TA L S

mapping, and the XmlAdapter class for more powerful DataSet-to-XML conversions, to name just a few). These may turn up again in separate toolkits or later versions of .NET, but for now developers are out of luck.

So, what does that leave us with? Here are some genuinely interesting ADO.NET changes that are still around:

•Provider factories: The dream of generic data access code (code you can write once and use with multiple different databases) takes a giant leap forward in .NET 2.0 thanks to provider factories—new components that can create strongly typed Connection, Command, and DataAdapter objects on the fly. You’ll learn about them in this chapter.

•Change notification: To build truly scalable web applications, you need to cache data that’s retrieved from a database so it can be reused without connecting to the data source each time. However, caching introduces the possibility of out-of-date information. ADO.NET includes a new change notification feature that you can use to automatically remove cached data when the related records in the database change. You’ll learn about this feature in Chapter 11.

•Connection statistics: It’s a small frill, but the new connection-tracking features of the SqlConnection object might help you profile different data access strategies. They’re introduced in this chapter.

•SQL Server 2005: SQL Server 2005 introduces a whole set of new features, and ADO.NET 2.0 supports them seamlessly. These features include user-defined data types that are based on .NET classes, as well as stored procedures written with .NET languages. For more information about these features, refer to a dedicated SQL Server 2005 book such as A First Look at Microsoft SQL Server 2005 for Developers (Addison-Wesley, 2004) or Pro SQL Server 2005 Assemblies (Apress, 2005).

The ADO.NET Architecture

ADO.NET uses a multilayered architecture that revolves around a few key concepts, such as Connection, Command, and DataSet objects. However, the ADO.NET architecture is quite a bit different from classic ADO.

One of the key differences between ADO and ADO.NET is how they deal with the challenge of different data sources. In ADO, programmers always use a generic set of objects, no matter what the underlying data source is. For example, if you want to retrieve a record from an Oracle database, you use the same Connection class you would use to tackle the same task with SQL Server. This isn’t the case in ADO.NET, which uses a data provider model.

ADO.NET Data Providers

A data provider is a set of ADO.NET classes that allows you to access a specific database, execute SQL commands, and retrieve data. Essentially, a data provider is a bridge between your application and a data source.

The classes that make up a data provider include the following:

•Connection: You use this object to establish a connection to a data source.

•Command: You use this object to execute SQL commands and stored procedures.

•DataReader: This object provides fast read-only, forward-only access to the data retrieved from a query.

•DataAdapter: This object performs two tasks. First, you can use it to fill a DataSet (a disconnected collection of tables and relationships) with information extracted from a data source. Second, you can use it to apply changes to a data source, according to the modifications you’ve made in a DataSet.

232 C H A P T E R 7 ■ A D O. N E T F U N D A M E N TA L S

When choosing a provider, you should first try to find a native .NET provider that’s customized for your data source. If you can’t find a native provider, you can use the OLE DB provider, as long as you have an OLE DB driver for your data source. The OLE DB technology has been around for many years as part of ADO, so most data sources provide an OLE DB driver (including SQL Server, Oracle, Access, MySQL, and many more). In the rare situation when you can’t find a dedicated .NET provider or an OLE DB driver, you can fall back on the ODBC provider, which works in conjunction with an ODBC driver.

■Tip Microsoft includes the OLE DB provider with ADO.NET so that you can use your existing OLE DB drivers. However, if you can find a provider that’s customized specifically for your data source, you should use it instead. For example, you can connect to a SQL Server database using either the SQL Server provider or the OLE DB provider, but the SQL Server provider will always perform best.

Standardization in ADO.NET

At first glance, it might seem that ADO.NET offers a fragmented model, because it doesn’t include a generic set of objects that can work with multiple types of databases. As a result, if you change from one RDBMS to another, you’ll need to modify your data access code to use a different set of classes.

But even though different .NET data providers use different classes, all providers are standardized in the same way. More specifically, each provider is based on the same set of interfaces and base classes. For example, every Connection object implements the IDbConnection interface, which defines core methods such as Open() and Close(). This standardization guarantees that every Connection class will work in the same way and expose the same set of core properties and methods.

Behind the scenes, different providers use completely different low-level calls and APIs. For example, the SQL Server provider uses the proprietary TDS (Tabular Data Stream) protocol to communicate with the server. The benefits of this model aren’t immediately obvious, but they are significant:

•Because each provider uses the same interfaces and base classes, you can still write generic data access code (with a little more effort) by coding against the interfaces instead of the provider classes. You’ll see this technique in action in the section “Provider-Agnostic Code.”

•Because each provider is implemented separately, it can use proprietary optimizations. (This is different from the ADO model, where every database call needs to filter through a common layer before it reaches the underlying database driver.) In addition, custom providers can add nonstandard features that aren’t included in other providers (such as SQL Server’s ability to perform an XML query).

ADO.NET also has another layer of standardization: the DataSet. The DataSet is an all-purpose container for data that you’ve retrieved from one or more tables in a data source. The DataSet is completely generic—in other words, custom providers don’t define their own custom versions of the DataSet class. No matter which data provider you use, you can extract your data and place it into a disconnected DataSet in the same way. That makes it easy to separate data retrieval code from data processing code. If you change the underlying database, you will need to change the data retrieval code, but if you use the DataSet and your information has the same structure, you won’t need to modify the way you process that data.

■Tip The next chapter covers the DataSet in much more detail. In this chapter, you’ll learn the fundamentals— how to use ADO.NET to perform direct, connection-based access.

SQL Server 2005

ADO.NET 2.0 provides support for a few features that are limited to SQL Server 2005. These features include the following:

MARS (multiple active result sets): This allows you to have more than one query on the go at the same time. For example, you could query a list of customers and then query a list of orders without closing the first query. This technique is occasionally useful, but it’s better if you can avoid the extra overhead.

User-defined data types: Using .NET code, you can define a custom class and then store instances of that class directly in a column of the database. This saves you the work of examining several fields in a row and then manually creating a corresponding data object to use in your application.

Managed stored procedures: SQL Server 2005 can host the CLR, which gives you the ability to write stored procedures in the database using pure C# code.

SQL notifications: Notifications allow your code to respond when specific changes are made in a database. In ASP.NET, this feature is most commonly used to invalidate a cached data object when one or more records are updated. This is the only SQL Server 2005 feature that’s also supported in SQL Server 7 and SQL Server 2000, albeit through a different mechanism.

Snapshot transaction isolation: This is a new transaction level that allows you to improve concurrency. It allows transactions to see a slightly older version of data while it’s being updated by another transaction.

For the most part, this book concentrates on programming techniques that work with all relational databases. However, Chapter 11 covers SQL notifications because they are of great use in many ASP.NET applications, and they are also supported in earlier versions of SQL Server through a different technology. This chapter briefly covers snapshot isolation. For information about other features that are specific to SQL Server 2005, you may want to consult A First Look at Microsoft SQL Server 2005 for Developers (Addison-Wesley, 2004) and Pro SQL Server 2005 Assemblies (Apress, 2005).

Fundamental ADO.NET Classes

ADO.NET has two types of objects: connection-based and content-based.

Connection-based objects: These are the data provider objects such as Connection, Command, DataAdapter, and DataReader. They execute SQL statements, connect to a database, or fill a DataSet. The connection-based objects are specific to the type of data source.

Content-based objects: These objects are really just “packages” for data. They include the DataSet, DataColumn, DataRow, DataRelation, and several others. They are completely independent of the type of data source and are found in the System.Data namespace.

In the rest of this chapter, you’ll learn about the first level of ADO.NET—the connection-based objects, including Connection, Command, and DataReader. You won’t learn about the higher-level DataAdapter yet, because the DataAdapter is designed for use with the DataSet and is discussed in Chapter 8. (Essentially, the DataAdapter is a group of related Command objects; these objects help you synchronize a DataSet with a data source.)

234 C H A P T E R 7 ■ A D O. N E T F U N D A M E N TA L S

■Note An ADO.NET provider is simply a set of ADO.NET classes (with an implementation of Connection, Command, DataAdapter, and DataReader) that’s distributed in a class library assembly. Usually, all the classes in the data provider use the same prefix. For example, the prefix Oracle is used for the ADO.NET Oracle provider, and it provides an implementation of the Connection object named OracleConnection.

The ADO.NET classes are grouped into several namespaces. Each provider has its own namespace, and generic classes such as the DataSet are stored in the System.Data namespaces. Table 7-1 describes the namespaces.

Table 7-1. The ADO.NET Namespaces

The Connection Class

The Connection class allows you to establish a connection to the data source that you want to interact with. Before you can do anything else (including retrieving, deleting, inserting, or updating data), you need to establish a connection.

The core Connection properties and methods are specified by the IDbConnection interface, which all Connection classes implement.

236 C H A P T E R 7 ■ A D O. N E T F U N D A M E N TA L S

There’s no reason to hard-code a connection string. As discussed in Chapter 5, the <connectionStrings> section of the web.config file is a handy place to store your connection strings. Here’s an example:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <connectionStrings>

<add name="Northwind" connectionString=

"Data Source=localhost;Initial Catalog=Northwind;Integrated Security=SSPI"/> </connectionStrings>

...

</configuration>

You can then retrieve your connection string by name from the WebConfigurationManager.ConnectionStrings collection, like so:

string connectionString = WebConfigurationManager.ConnectionStrings["Northwind"].ConnectionString;

The following examples assume you’ve added this connection string to your web.config file.

Testing a Connection

Once you’ve chosen your connection string, managing the connection is easy—you simply use the Open() and Close() methods. You can use the following code in the Page.Load event handler to test a connection and write its status to a label (as shown in Figure 7-2):

// Create the Connection object. string connectionString =

WebConfigurationManager.ConnectionStrings["Northwind"].ConnectionString; SqlConnection con = new SqlConnection(connectionString);

try

{

// Try to open the connection. con.Open();

lblInfo.Text = "<b>Server Version:</b> " + con.ServerVersion; lblInfo.Text += "<br /><b>Connection Is:</b> " + con.State.ToString();

}

catch (Exception err)

{

// Handle an error by displaying the information. lblInfo.Text = "Error reading the database. "; lblInfo.Text += err.Message;

}

finally

{

//Either way, make sure the connection is properly closed.

//Even if the connection wasn't opened successfully,

//calling Close() won't cause an error.

con.Close();

lblInfo.Text += "<br /><b>Now Connection Is:</b> "; lblInfo.Text += con.State.ToString();

}

Figure 7-2 shows the results of running this code.

Figure 7-2. Testing a connection

Connections are a limited server resource. This means it’s imperative that you open the connection as late as possible and release it as quickly as possible. In the previous code sample, an exception handler is used to make sure that even if an unhandled error occurs, the connection will be closed in the finally block. If you don’t use this design and an unhandled exception occurs, the connection will remain open until the garbage collector disposes of the SqlConnection object.

An alternate approach is to wrap your data access code in a using block. The using statement declares that you are using a disposable object for a short period of time. As soon as the using block ends, the CLR releases the corresponding object immediately by calling its Dispose() method. Interestingly, calling the Dispose() method of a Connection object is equivalent to calling Close(). That means you can rewrite the earlier example in the following, more compact, form:

string connectionString = WebConfigurationManager.ConnectionStrings["Northwind"].ConnectionString;

SqlConnection con = new SqlConnection(connectionString);

using (con)

{

con.Open();

lblInfo.Text = "<b>Server Version:</b> " + con.ServerVersion; lblInfo.Text += "<br /><b>Connection Is:</b> " + con.State.ToString();

}

lblInfo.Text += "<br /><b>Now Connection Is:</b> "; lblInfo.Text += con.State.ToString();

The best part is that you don’t need to write a finally block—the using statement releases the object you’re using even if you exit the block as the result of an unhandled exception.

Connection Pooling

Acquiring a connection takes a short, but definite, amount of time. In a web application in which requests are being handled efficiently, connections will be opened and closed endlessly as new requests are processed. In this environment, the small overhead required to establish a connection can become significant and limit the scalability of the system.

One solution is connection pooling. Connection pooling is the practice of keeping a permanent set of open database connections to be shared by sessions that use the same data source. This avoids the need to create and destroy connections all the time. Connection pools in ADO.NET are completely transparent to the programmer, and your data access code doesn’t need to be altered. When a client requests a connection by calling Open(), it’s served directly from the available pool, rather than re-created. When a client releases a connection by calling Close() or Dispose(), it’s not discarded but returned to the pool to serve the next request.