What Is the Data Access Application Block?

The Data Access Application Block provides a set of classes and interfaces that encapsulate many of the best practices that Microsoft recommends for designing a data layer.^[1] Specifically, Enterprise Library's Data Access Application Block provides a solution that satisfies the requirements for using data access helper components to produce cleaner and more manageable code. The Data Access Application Block also uses an abstract base class that defines a common interface for these components. This lets you write code that uses the Data Access Application Block to be very portable; that is, the code can generally remain unchanged when switching between different databases (e.g., from a Microsoft SQL Server database to an Oracle or DB2 database). By making the most of the Data Access Application Block, an enterprise can do the following.

^[1] See Application Architecture for .NET: Designing Applications and Services at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp.

• Maintain consistent data access practices, both in an application and across the enterprise.

• Reduce difficulties in changing the physical database target.

• Relieve developers from having to learn different programming models for different types of databases.

• Reduce the amount of code that needs to be rewritten when porting applications to different types of databases.

• Provide a single point of interception for data access monitoring and testing.

• Allow developers to abstract the data access code from the code related to business logic. This has the benefit of reducing and simplifying the code that usually exists in data access logic components.

Earlier versions of the Microsoft Data Access Application Block provided an implementation for data access helper components. These versions, however, focused solely on providing support for Microsoft SQL Server. The data access helper component for the previous versions was named SqlHelper. Separate implementations of the entire application block were then made available for Oracle and OLE DB. The data access helper components in those implementations were named OracleHelper and OleDbHelper respectively. Although these components were very similar, there was no single application block that focused on providing a uniform and consistent interface across different database vendors.

All of the features that existed in the previous versions of the Data Access Application Block still exist in the Enterprise Library version. The primary difference, however, is that the data access helper components in the Enterprise Library version have not been designed just for Microsoft SQL Server and then ported to support other database vendors. Instead, a generic abstract base class, named Database, has been designed that serves as the uniform interface for all types of databases. This class, coupled with a DatabaseFactory class that uses configuration data to create concrete implementations of the Database class, provides new benefits.

• Code can be written against the base class' interface so it is agnostic as to the underlying data source. For example, code can be written to consume data from and provide data to an Oracle database so that it is no different than the code needed to work with a SQL Server database.

  If an application must be ported from one data source to another, very little, if any code needs to be changed. Not only does this enhance database portability, but it also provides for "developer portability" as it gives developers a consistent interface that is independent of the type of database that may be needed.

  It is also important to note that just because an application is "database portable," this doesn't eliminate the need to retest that application after it has been ported to another database. Occasionally, differences may exist in the way one database vendor supports certain functionality (e.g., retrieving an "identity" value) that may ultimately cause unforeseen differences in an application. While the Data Access Application Block strives to support database portability, it cannot guarantee it.

• The ultimate data source that is used by an application is determined at runtime from configuration information. Not only does this allow an application to switch from one data source to another without needing to restart, but it also allows new data sources to be created and "snapped in" on the fly.

  If you need support for a database provider other than those supplied by Enterprise Library (i.e., Microsoft SQL Server, Oracle, and DB2), you can create that database provider (or if available, download one from a site like www.gotdotnet.com) and plug it into the configuration data for any application.