The following tip was excerpted from Chapter 1, 'Migrating from ADO to ADO.NET,' of the book Expert One-on-one Visual Basic 2005 Database Programming by Roger Jennings, courtesy of Wiley Publishers. Click here for the complete collection of book excerpts.
Microsoft designed ADO.NET to maximize the scalability of data-intensive Windows and Web form applications and .NET components. Scalability isn't a critical factor when your project involves a few
Windows form clients retrieving and updating tables in a single database. High-traffic Web sites, however, require the ability to scale up by adding more processors and RAM to a single server or to scale out by adding more application servers to handle the data processing load. Managed ADO.NET code that minimizes the duration and number of concurrent database server connections and uses optimistic concurrency tests for updating tables is the key to achieving a scalable data-intensive .NET project.
The sections that follow explain the role of ADO.NET 2.0 namespaces and managed data providers, which form the foundation of .NET 2.0 data access operations.
The System.Data Namespace
The .NET Framework 2.0 System.Data namespace contains all ADO.NET 2.0 namespaces, classes,
interfaces, enumerations, and delegates. Figure 1-1 shows Object Browser displaying the System.Data
namespaces.
Figure 1-1
VS 2005 doesn't add a reference to the System.Data.dll assembly automatically when you start a new Windows form project. Creating a new data source with the Data Source Configuration Wizard adds
references to the System.Data and System.Xml namespaces. The section "Add a Typed DataSet
from an SQL Server Data Source," later in this chapter, describes how to use the Data Source
Configuration Wizard.
ADO.NET SqlConnection and SqlCommand objects correspond to ADODB.Connection and
ADODB.Command objects, but are restricted to use with SQL Server databases. Following are the
ADO.NET namespace hierarchies for SqlConnection- and SqlCommand-managed data provider
objects; namespaces new in ADO.NET 2.0 are emphasized:
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Data.Common.DbConnection
System.Data.SqlClient.SqlConnection
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Data.Common.DbCommand
System.Data.SqlClient.SqlCommand
The following table provides brief descriptions of the System.Data namespaces shown in Figure 1-1 with the namespaces in the preceding hierarchy listed in order.
| Namespace |
Description |
| System.Object |
The root of the .NET Framework 2.0 type hierarchy (member of System). |
| System.MarshalByRefObject |
Enables remoting of data objects across application domain boundaries (member of System). |
| System.ComponentModel |
Supports object sharing between components and enables runtime and design-time implementations of components. |
| System.Data |
Provides the base classes, interfaces, enumerations, and event handlers for all supported data sources -- primarily relational data and XML files or streams. |
| System.Data.Common |
Provides classes that all managed data providers share, such as DbConnection and DbCommand in
the preceding hierarchy list. |
| System.Data.Common.DbConnection |
Provides inheritable classes for technology-specific and vendor-specific data providers (new in
ADO.NET 2.0). |
| System.Data.Odbc, System.Data OleDb, System.Data.OracleClient System.Data.SqlClient, and System.Data.SqlCeClient |
Namespaces for the five managed data providers included in ADO.NET 2.0; the next section describes these namespaces. |
| System.Data.SqlTypes |
Provides a class for each SQL Server data type, including SQL Server 2005's new xml data type;
these classes substitute for the generic DbType enumeration that supports all data providers. |
| System.XML |
Adds the System.Xml.XmlDataDocument class, which supports processing of structured XML documents by DataSet objects. |
After you add a project reference to System.Data.dll, you can eliminate typing System.Data namespace qualifiers and ensure strict type checking by adding the following lines to the top of your class code:
Option Explicit On
Option Strict On
Imports System.Data
Imports System.Data.SqlClient
Specifying Option Explicit On and Option Strict On in the Options dialog's Projects and Solutions,
VB Defaults page doesn't ensure that other developers who work with your code have these defaults set.
Substitute Imports System.Data.OleDb for Imports System.Data.SqlClient if you're using the OleDb data provider.
The above tip was excerpted from Chapter 1, 'Migrating from ADO to ADO.NET,' of the book Expert One-on-one Visual Basic 2005 Database Programming by Roger Jennings, courtesy of Wiley Publishers. Click here for the complete collection of book excerpts.
