What Does the Data Access Application Block Do?

The Data Access Application Block includes a small number of methods that simplify the most common techniques for accessing a database. Each method encapsulates the logic required to retrieve the data and manage the connection to the database. The methods exposed by the block allow you to execute queries, return data in a range of different formats, populate a DataSet, update the database from a DataSet, perform data access asynchronously (against SQL Server databases), and return data as objects in a suitable format for use with client-side query technologies such as LINQ.

ADO.NET 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 specific features of each database type, such as parameter discovery and type conversion. As a result, applications can often 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 provides much of the implementation required by the data access methods available in ADO.NET.

The application block also includes classes designed to work with Microsoft SQL Server, Microsoft SQL Server CE, and Oracle. These classes perform operations that are specific 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 when creating the Database implementation it uses as a facade for the majority of the methods. 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 types without recompiling their code.

Example Application Code

The following code shows how to call a stored procedure that returns a DataSet. This example assumes that you have resolved this class through the Enterprise Library container to inject the instance of the Database class.

public void ExampleScenario(Database db)
{
  DbCommand dbCommand = db.GetStoredProcCommand("GetProductsByCategory");

  // Retrieve products from category 7.
  db.AddInParameter(dbCommand, "CategoryID", DbType.Int32, 7);
 
  DataSet productDataSet = db.ExecuteDataSet(dbCommand); 
}

'Usage
Public Sub ExampleScenario(ByVal db As Database)

  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)

End Sub

For information about resolving Enterprise Library objects in your applications, see Creating and Referencing Enterprise Library Objects.