Partager via

When Should I Use the Data Access Application Block?

  • Article

You should consider using the Data Access Application Block if your application uses standard data access techniques. The block is particularly suited to querying, retrieving, and updating data through implementations based on the ExecuteReader, ExecuteXmlReader, and ExecuteNonQuery methods commonly used in ADO.NET—including the asynchronous versions of these methods. It also provides methods to populate DataSet instances, and flush the changes back to the database.

You should also consider using the block if you want to work with data using client-side querying mechanisms such as Language Integrated Query (LINQ). It contains support for these programming techniques by exposing methods that return data as sequences of objects.

A third reason for using the Data Access Application Block is its capability to abstract the database type. This makes it easier to change your application to use a different type of database if required, although some of the more advanced data access methods do rely on the specific capabilities of the underlying ADO.NET Data Provider.

Scenarios for the Data Access Application Block

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 most common tasks developers face when they are writing database applications 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
  • Updating a database with data contained in a DataSet object
  • Retrieving XML data from a SQL Server database
  • Querying the data returned using client-side techniques such as LINQ
  • Performing asynchronous data access with a callback handler or Lambda expression

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

Benefits of the Data Access Application Block

The Data Access Application Block provides the following benefits:

  • It uses the functionality provided by ADO.NET, and you also can use ADO.NET functionality along with the application block's functionality.
  • It reduces the need to write boilerplate code to perform standard tasks.
  • It helps maintain consistent data access practices, both within an application and across the enterprise.
  • It makes it easier to change the database type.
  • It relieves developers from learning different programming models for different types of databases.
  • It reduces the amount of code that developers must write when they port applications to different types of databases.

Limitations of the Data Access Application Block

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 be a better option.

The Data Access Block cannot be used in applications that target the .NET Framework 4.0 Client Profile. It can only be used in applications that target the full .NET Framework 4.0 Profile. For information about profiles in the .NET Framework 4.0, see .NET Framework Client Profile on MSDN. For information about changing the targeted profile, see How to: Target a Specific .NET Framework Version or Profile on MSDN.

The OracleClient data provider is deprecated in version 4.0 of the .NET Framework, although it is still supported by the Enterprise Library 5.0. For future development, consider choosing a different Oracle driver, such as that available from the Enterprise Library Contrib site.