Enterprise Library for .NET Framework 1.1

Summary

This page provides an overview of the Enterprise Library Data Access Application Block. This is reusable and extensible source code-based guidance that simplifies development of common data access functionality in .NET-based applications.

Contents

Introduction to the Data Access Application Block
Design of the Data Access Application Block
Test Drive
Feedback and Support
June 2005 Release Updates
Roadmap
Authors and Contributors
Related Titles

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 the application block in a variety of situations, such as reading data for display, obtaining data to pass 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, and 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 frequently used features of ADO.NET.

The application block also facilitates the development of portable application code, allowing the code to remain uniform across multiple database servers, including Microsoft SQL Server, Oracle, and DB2. It does so by using an abstract base class that defines a common interface and provides much of the implementation for the data access methods, Applications written for one type of database—such as SQL Server—look the same as applications written for another type of database, such as Oracle. By using the Data Access Application Block and by following the guidelines in this document, your code remains mostly portable.

Another feature is that application code can refer to particular databases by name, such as "Customer" or "Inventory." Changing the name in the application configuration allows developers to use their applications with different database configurations, without having to recompile their code.

The Data Access Application Block has the following features:

• It reduces the need to write boilerplate code to perform standard tasks.
• It helps maintain consistent data access practices, both in an application and across the enterprise.
• It reduces difficulties in changing the physical database target.
• It relieves developers from learning different programming models for different types of databases.
• It reduces the amount of code that needs to be rewritten when porting applications to different types of databases.

Common Scenarios

Developers often write applications that use databases. Because it is so common, developers may find themselves writing the same code over and over, 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 an implementation of the most common data access tasks. Developers only need to do the following:

1. Create the database object.
2. Supply the parameters for the command, if they are needed.
3. Call the appropriate method.

These methods are optimized for performance. They are also portable. The Data Access Application Block works transparently with SQL Server, DB2, and Oracle databases.

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 C# development tool or Microsoft Visual Basic development system
• .NET Framework
• Microsoft SQL Server, Oracle, or DB2 databases

Highlights of the Enterprise Library Data Access Application Block

The Enterprise Library Data Access Application Block includes the following new features:

• A graphical tool for managing configuration settings
• Support for multiple database systems, with the ability to add additional systems
• A factory and named instances that abstract the database and the connection string, respectively
• Support for parameter caching has been expanded to allow applications to clear the cache

Migrating from Previous Versions of the Data Access Application Block

Users of earlier releases of the Data Access Application Block should recognize many of the scenarios addressed by the Enterprise Library version. While the current version builds on the knowledge and feedback gained from earlier releases, it represents a significant change in how those scenarios are addressed.

The following list describes the changes between the Enterprise Library version of the Data Access Application Block and earlier versions:

• The static helper methods available in the earlier versions of the application block have been replaced by methods on instantiated data access objects.
• Another style of overloads that accepts new data access objects is now provided. When using this style, all data access functionality is exposed through two overloads, one to use when executing commands outside of a transaction and another to use when executing commands inside of a transaction.
• The numerous overloads for each data access method have been reduced.
• The database-specific object is created with a factory, which uses configuration information to determine the type of object to create.
• Connection string information has been moved to a configuration file and is no longer used on the method calls. Using the Enterprise Library Configuration Console allows you to configure your databases, and if needed, encrypt the configuration information in storage.
• A separate class now represents command information. Developers create and initialize a command object, which is then passed to the appropriate method in the Database class.

The following code illustrates an application using the Data Access Application Block to perform a database query that returns a dataset.

[C#]
myDataSet =  DatabaseFactory.CreateDatabase("Sales").ExecuteDataSet("GetO rdersByCustomer", myCustomerId );

[VB]
myDataSet =  DatabaseFactory.CreateDatabase("Sales").ExecuteDataSet("GetO rdersByCustomer", myCustomerId);

Notice that the code the developer writes references the database by name. The actual database type and connection string are stored in the configuration.

System Requirements

To develop applications using the Data Access Application Block, you need the following:

• Microsoft Windows 2000, Windows XP Professional, or Windows Server 2003 operating system
• Microsoft .NET Framework 1.1
• Microsoft Visual Studio .NET 2003
• A database server running SQL Server 7.0 or later, Oracle 9i, or DB2 (If you are using a DB2 database, you also need the IBM UDB 8.1.2 data provider)

Data Access Application Block Dependencies

The application blocks that are provided with the Enterprise Library are designed to be used in conjunction with each other. Sometimes, the application blocks have dependencies on other application blocks and code that is included with the Enterprise Library. The Data Access Application Block has the following dependencies:

• The Configuration Application Block. The Data Access Application Block uses the Configuration Application Block to read its configuration information.
• Common library functionality, such as instrumentation. It provides various functions for exposing events and data used for system management.

By default, the application block uses XML files to store configuration information. The recommended way to modify this information is to use the Enterprise Library Configuration Console.

You can use the Enterprise Library Configuration Console to encrypt and protect the database configuration information containing connection strings. Connection strings may contain passwords, network addresses, and other sensitive information. To learn more about encrypting configuration settings, see the documentation for the Enterprise Library Configuration Application Block.

Design of the Data Access Application Block

The Data Access Application Block was designed to achieve the following goals:

• To encapsulate the logic used to perform the most common data access tasks
• To relieve developers of the need to write duplicate code for common data access tasks
• To minimize the need for custom code
• To incorporate best practices for data access, as described in the .NET Data Access Architecture Guide.
• To perform within 5 percent of ADO.NET s efficiency
• To have a small number of objects and classes
• To ensure that all of the application block s functions work identically for different types of databases
• To ensure that applications written for one type of database are, in terms of data access, the same as applications written for another type of database
• To use database connection information stored in configuration

Design Highlights

Figure 1 shows the interrelationship between the key classes in the Data Access Application Block.

Figure 1. Design of the Data Access Application Block

The abstract base class Database defines the common interface and provides much of the implementation for the data access methods. The SqlDatabase, OracleDatabase and Db2Database classes derive from the Database class. They provide methods to their respective database server systems, which include common functionality that is implemented differently from database to database, as well as functionality unique to that database system.

Database commands and parameters are handled differently across database systems. The abstract class DbCommandWrapper provides the interface definition for database-specific classes that will wrap IDbCommand and provide parameter handling.

The DatabaseFactory class provides a static method, CreateDatabase, to encapsulate the logic that creates the appropriate Database object. By using the factory to create the correct database object, the client code is not bound to a specific database type.

The DatabaseFactory class uses the Configuration Application Block to retrieve the required configuration information, including the fully qualified type name and the connection string of the specific Database-derived class to be created.

The application block supports the dynamic discovery of parameters. This discovery requires a round trip to the database system. The ParameterCache class allows parameter information to be cached, thus avoiding round trips for subsequent invocations of the same stored procedure.