Introduction to the Data Access Application Block

This topic includes a series of brief sections that provide information to help you decide if the Data Access Application Block is suitable for your requirements. This topic includes the following sections:

• Common Scenarios
• Example Application Code
• Changed Features, Version 3.1 and Later
• When to Use the Data Access Application Block
• When to Use ADO.NET Directly

In addition to this introductory material, the documentation also contains the following topics:

• Developing Applications Using the Data Access Application Block. This describes how to configure the application block, how to prepare your application to use the Data Access Application Block, and contains details of specific features of the application block such as how you create a database, work with transactions, and handle parameters and exceptions.
• Key Scenarios. This section demonstrates how to use the application block to perform the most typical data access operations.
• Design of the Data Access Application Block. This section describes the decisions that went into designing the application block and the rationale behind those decisions.
• Extending and Modifying the Data Access Application Block. This section describes how to extend the application block by adding your own database provider and gives suggestions for modifying the source code.
• Deployment and Operations. This section describes how to deploy and update the application block assemblies. It also contains information about configuration and SQL Server security.
• Data Access QuickStart. This section describes how to install and configure the QuickStart application and contains a series of walkthroughs that demonstrate how to incorporate common data access operations into an application.

For details of the system requirements for the Data Access Application Block, see System Requirements. For details of the dependencies for the Data Access Application Block, see Application Block Dependencies.

Common Scenarios

Developers often write applications that use databases. Because it is so common, developers may find themselves repeatedly writing the same code for each application. In addition, these applications may need to work with different types of databases. Although the tasks are the same, the code must be adapted to suit the programming model of each database. The Data Access Application Block solves these problems by providing the logic to perform the most common data access tasks. Developers only need to do the following:

• Create the database object.
• Supply the parameters for the command, if they are needed.
• Call the appropriate method(s). These methods are optimized for performance. They are also portable.

The Data Access Application Block works transparently with SQL Server, SQL Server CE, and Oracle databases. It is designed to address the most common tasks developers face when they are writing database applications. These tasks are arranged according to scenarios. Each scenario gives an example of a real-world situation, such as retrieving information from a catalog or performing a banking transaction, describes the database functions the situation requires, and shows the code that accomplishes the task.

The goal of arranging these tasks according to scenarios is to give the code some context. Instead of showing an isolated group of methods, with no sense of where they can best be used, scenarios provide a setting for the code, placing it in situations familiar to many developers whose applications must access databases.

The scenarios are the following:

• Using a DataReader to retrieve multiple rows of data
• Using a DataSet to retrieve multiple rows of data
• Executing a command and retrieving the output parameters
• Executing a command and retrieving a single-value item
• Performing multiple operations within a transaction
• Retrieving XML data from a SQL Server
• Updating a database with data contained in a DataSet object

For more information about each of these scenarios, see Key Scenarios.

Example Application Code

The following code shows how to call a stored procedure that returns a DataSet.

Database db = DatabaseFactory.CreateDatabase();

DbCommand dbCommand = db.GetStoredProcCommand("GetProductsByCategory");

// Retrieve products from category 7.
db.AddInParameter(dbCommand, "CategoryID", DbType.Int32, 7);

DataSet productDataSet = db.ExecuteDataSet(dbCommand); 

'Usage
Dim db As Database = DatabaseFactory.CreateDatabase()

Dim dbCommand As DbCommand = db.GetStoredProcCommand("GetProductsByCategory")

' Retrieve products from the category 7.
db.AddInParameter(dbCommand, "CategoryID", DbType.Int32, 7)

Dim productDataSet As DataSet = = db.ExecuteDataSet(dbCommand)

Changed Features, Version 3.1 and Later

In general, applications built using earlier releases of the Data Access Application Block will function with this release without the need for any code changes. It may be necessary to update the references to refer to the new assemblies and to update the configuration files to reference the correct version of the assemblies. However, some changes were made to the Data Access Application Block in version 3.1 (May 2007), which may affect applications written for earlier versions if you upgrade to the current version of Enterprise Library. The following sections describe these changes.

The .NET Framework 2.0 TransactionScope Class

To take advantage of the .NET Framework 2.0 TransactionScope class, there have been changes to some of the Database class methods in version of Enterprise Library from version 3.1 onwards. These methods, such as ExecuteNonQuery, have been modified to recognize when a TransactionScope instance is active by replacing the GetConnection method with the GetOpenConnection method. If you have written a class that inherits from the Database class, you will need to rewrite your code to take these changes into account. If you continue to use the GetConnection method, you will receive a compiler warning. In addition, if your application uses the ExecuteXmlReader method, you may need to rewrite your code to test to see whether a TransactionScope instance is active before closing a connection.

For more information, see Using the TransactionScope Class. For an example of how to use the ExecuteXMLReader method, see Retrieving Multiple Rows As XML.

SQL Server Compact Edition

Enterprise Library 3.1 — May 2007 and later supports SQL Server Compact Edition (CE). SQL Server CE provides the essential features of a relational database and is intended for desktop and mobile applications that need a local data store but do not require the full functionality of SQL Server. For more information, see the section "Using SQL Server CE" in Creating a Database Object.

When to Use the Data Access Application Block

The Data Access Application Block includes a small number of methods that simplify the most common methods of accessing a database. Each method encapsulates the logic required to retrieve the data and manage the connection to the database. You should consider using the application block if your application uses standard data access techniques.

The application block supplements the code in ADO.NET that allows you to use the same code with different database types. It includes classes for SQL Server and Oracle databases. These classes contain code that provides database-specific implementations for features such as parameter handling and cursors. In addition, the GenericDatabase class allows you to use the application block with any configured ADO.NET DbProviderFactory object. You can extend the application block by adding new database types that include database-specific features or that provide a custom implementation of an existing database. The only requirement is that an ADO.NET DbProviderFactory class exists for the target database.

When to Use ADO.NET Directly

The Data Access Application Block is a complement to ADO.NET; it is not a replacement. The application block provides simplicity and convenience while helping developers use ADO.NET with best practices. If your application needs to retrieve data in a specialized way, or if your code needs customization to take advantage of features specific to a particular database, using ADO.NET might better suit you.