Data Access Application Block

Data Access Application Block

Enterprise Library for .NET Framework 1.1

patterns & practices Developer Center

Microsoft Corporation

June 2005

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.

* Important Note: The January 2005 release of Enterprise Library is no longer available to download, due to important issues discovered after the release. Customers building new applications should move to the June 2005 release. Customers who have already adopted the January release must apply the patches available on Enterprise Library Community site. Please direct any questions to the community site or to devfdbck@microsoft.com

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

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.

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.

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

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

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("GetOrdersByCustomer", myCustomerId );

[VB]
myDataSet = DatabaseFactory.CreateDatabase("Sales").ExecuteDataSet("GetOrdersByCustomer", 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.

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)

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.

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

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.

The Data Access Application Block has been developed as a result of analyzing common enterprise development challenges and successful solutions to these challenges. However, because each application is unique, you will not find this application block suitable for every application. To evaluate this application block and determine its applicability to your projects, Microsoft suggests you dedicate at least half of a day to explore the application block. The following is a suggested evaluation approach:

1. Download Enterprise Library.
2. Install Enterprise Library and compile all application blocks and tools.
3. Read the "Introduction" and "Scenarios and Goals" sections of the documentation.
4. Run the scripts to configure the application block's QuickStart samples.
5. Compile and run the QuickStart samples, and read through the related "QuickStart Walkthroughs" and "Key Scenarios" sections of the documentation
6. If the application block looks like a good fit for your application, try implementing a simple use case in your application or in a throw-away prototype application using the application block.

Questions? Comments? Suggestions? To provide feedback about this application block, or to get help with any problems, please see the Enterprise Library Community site. The community site is the preferred feedback and support channel as it allows you to share your ideas, questions, and solutions with the entire community. Alternatively, you can send e-mail directly to the Microsoft patterns & practices team at devfdbck@microsoft.com, although we are unable to respond to every message.

Enterprise Library is a guidance offering, designed to be reused, customized, and extended. It is not a Microsoft product. Code-based guidance is shipped "as is" and without warranties. Customers can obtain support through Microsoft Support Services for a fee, but the code is considered user-written by Microsoft support staff. For more information about our support policy, see the Enterprise Library home page

The June 2005 release of Enterprise Library is a minor update of the original version released in January 2005. Please see About the June 2005 Release for more information on the updates to the application blocks for the June 2005 release.

An updated release of the Data Access Application Block is planned for the next release of Enterprise Library. This release will target the .NET Framework 2.0 and Visual Studio 2005 and will include additional improvements based on customer feedback.

The Enterprise Library Data Access Application Block was produced by the following people:

• Program Managers: William Loeffler (Microsoft Corporation), Linh Nguyen (Avanade Inc)
• Product Manager: Tom Hollander (Microsoft Corporation)
• Architects: Edward Jezierski (Microsoft Corporation), Kyle Huntley (Avanade Inc)
• Development: Scott Densmore, Peter Provost, Lenny Fenster (Microsoft Corporation), Brian Button (Murphy and Associates), Fernando Simonazzi (Clarius Consulting)
• Test: Mohammad Al-Sabt, Carlos Farre (Microsoft Corporation), Mani Krishnaswami, Gokulaprakash Thilagar, Rohit Sharma, Prashant Bansode, Jeevarani Radhakrishnan, Dhananjaya Rao (Infosys Technologies Ltd), Pavan Kumar Sura (Volt)
• Documentation and Samples: RoAnn Corbisier (Microsoft Corporation), Tim Osborn (Ascentium Corporation), Roberta Leibovitz (Modeled Computation LLC), Paul Slater (Wadeware LLC), Tina Burden McGrayne (Linda Werner & Associates Inc)

Many thanks to the following advisors who provided invaluable assistance:

• Rudy Araujo, Yen-Ming Chen, Mark Curphey and David Raphael of Foundstone Inc.
• Benoit Morneau and Shoichi Takasaki of Bowne Global Solutions

• .NET Data Access Architecture Guide
• Enterprise Library

Start | Previous | Next