Introduction to the Data Access Application Block

The Enterprise Library Data Access Application Block simplifies development tasks that implement common data access functionality. Applications can use this application block in a variety of situations, such as reading data for display, passing data through application layers, and submitting changed data back to the database system. The application block includes support for both stored procedures and in-line SQL. Common housekeeping tasks, such as managing connections and creating and caching parameters, are encapsulated in the application block's methods. In other words, the Data Access Application Block provides access to the most often used features of ADO.NET in simple-to-use classes; this boosts developer productivity.

ADO.NET 2.0 provides classes such as the DbCommand class and the DbConnection class; these classes help to abstract the data provider from any particular database implementation. The Data Access Application Block takes advantage of these classes and provides a model that further supports encapsulation of database type-specific features, such as parameter discovery and type conversions. Because of this, applications can be ported from one database type to another without modifying the client code. The Data Access Application Block includes an abstract base class that defines a common interface and that provides much of the implementation needed by the data access methods available in ADO.NET 2.0.

The application block also includes classes that are specific to Microsoft SQL Server, Microsoft SQL Server CE, and Oracle. These classes perform operations that are particular to the database type. The code for applications written for one type of database, such as SQL Server, looks much the same as the code for applications written for another type of database, such as Oracle.

Another feature of the Data Access Application Block is that application code can refer to particular databases by an ADO.NET connection string name, such as "Customer" or "Inventory." The application code can specify a named instance of a database and pass this parameter to the DatabaseFactory.CreateDatabase method. Each named database has its connection information stored in a configuration file. By changing the settings in the configuration file, developers can use their applications with different database configurations without recompiling their code.

The Data Access Application Block provides the following benefits:

• It uses the functionality provided by ADO.NET 2.0 and with it, you 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 reduces difficulties in changing 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.

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.

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)

Audience Requirements

This guide is intended for software architects and software developers. To benefit fully from this guide, you should have an understanding of the following technologies:

• Microsoft Visual Studio 2005 development system (any of the following editions):

  Visual Studio 2005 Professional Edition

  Visual Studio 2005 Team System Edition

  Visual Studio 2005 Standard Edition

• .NET Framework version 2.0

• Microsoft SQL Server, Microsoft SQL Server CE or Oracle database

Migrating to Enterprise Library 3.1 — May 2007

In general, applications built using the January 2006 release of the Data Access Application Block will function with the May 2007 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.

To take advantage of the .NET Framework 2.0 TransactionScope class there have been changes to some of the Database class methods. 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 if a TransactionScope instance is active before closing a connection.

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

New Features

Enterprise Library 3.1 – May 2007 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 Using SQL Server CE.

There is a new overload of the Database.UpdateDataSet method that takes an updateBatchSize parameter. Setting the UpdateBatchSize parameter to a positive integer value causes the DataAdapter object to send updates to the database as batches of the specified size. This reduces the number of database round trips.

System Requirements

To run the Data Access Application Block, you need the following:

• Microsoft Windows XP Professional, Windows Server 2003, or Windows Vista operating system

• Microsoft .NET Framework 2.0

• Microsoft Visual Studio 2005 development system (any of the following editions):

  Microsoft Visual Studio 2005 Standard Edition

  Microsoft Visual Studio 2005 Professional Edition

  Microsoft Visual Studio 2005 Team Edition for Software Developers

  Microsoft Visual Studio 2005 Team Edition for Software Testers

  Microsoft Visual Studio 2005 Team Edition for Software Architects

  Microsoft Visual Studio 2005 Team Suite

• A database server running a database that is supported by a .NET Framework 2.0 data provider. This includes SQL Server 2000 or later, SQL Server CE and Oracle 9i of later. The database server can also run a database that is supported by the .NET Framework 2.0 data providers for OLE DB or ODBC.

Data Access Application Block Dependencies

The Data Access Application Block depends on other code included in the Enterprise Library:

• Core library functionality. The Enterprise Library Core provides services, such as instrumentation and configuration, and is a shared dependency of all Enterprise Library application blocks. The core library functionality is contained in the assembly Microsoft.Practices.EnterpriseLibrary.Common.dll.
• The ObjectBuilder subsystem. The ObjectBuilder subsystem performs all the repetitive and necessary tasks for creating and disposing object instances, while still providing a high level of flexibility. Enterprise Library uses the ObjectBuilder subsystem for tasks such as injecting configuration into block classes and connecting instrumentation classes to application blocks. The ObjectBuilder subsystem is contained in the assembly Microsoft.Practices.ObjectBuilder.dll.

The Data Access Application Block uses ADO.NET for the management of connection strings. The application block provides a DatabaseFactory class that uses configuration information to create a database object. This configuration information consists of both the ADO.NET-managed connection strings and other application block configuration information.

Generally, you should manage connection strings using configuration data. Alternatively, you can create a database object in your application by using a constructor and supplying it with a connection string and the database type.

The recommended way to modify the Data Access Application Block configuration information is to use the Enterprise Library Configuration Console.

Data Access Application Block Documentation

In addition to the introduction, the documentation contains the following sections:

• Developing Applications with the Data Access Application Block. This section is divided into several subsections. Entering Configuration Information describes how to configure the application block. Adding Application Code describes how to prepare your application to use the Data Access Application Block. The next subsection, Key Scenarios, demonstrates how to use the application block to perform the most typical data access operations. The last subsection, Details of Development Tasks, includes in-depth information about creating database objects, creating commands, handling parameters, and handling exceptions.
• 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 and also contains information about configuration and SQL Server security.
• QuickStarts. 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.

More Information

For more information, see the following resources:

• Application Architecture for .NET: Designing Applications and Services
• .NET Data Access Architecture Guide
• INFO: Microsoft Guide for Designing Data Tier Components and Passing Data Through Tiers
• Improving Web Application Security: Threats and Countermeasures
• Improving .NET Application Performance and Scalability