The Enterprise Library is a collection of Application Blocks released by the Patterns and Practices group within Microsoft. (http://www.microsoft.com/resources/practices/default.mspx). It is an update to the previous Application Blocks for .NET that includes complete architectural changes for most of the blocks.

An Application Block can be thought of as an add-on to the .NET development environment. They are reusable components that encapsulate Microsoft best practices in each area.

The seven blocks consist of:

1. Caching
2. Configuration
3. Cryptography
4. Data Access
5. Exception Handling
6. Logging and Instrumentation
7. Security

Each block is well-documented and includes complete source code. In fact, when you download the library you will find that no compiled assemblies are included. In order to implement these products, you must compile each one from the included source code. Fortunately, there is an included batch file that will do all the work for you. In addition, the documentation clearly covers installation, implementation and deployment for all blocks.

Over the next few articles, we will cover each block, detailing the pros and cons of using it, how to implement them in a real world environment and how they relate and depend on each other. The first two we will examine is the Data Access Application Block(DAAB) and the Configuration Application block(ConfAB).

The ConfAB is integral to using all the other six blocks as well. The main purpose of this block is to manage application-level configuration data. Included in the functionality of this block is the ability to store the data regardless of the actual data store. Whether you implement XML files, a Database store or a good old-fashioned flat file, the ConfAB will provide read and write capabilities. It does this by using storage providers and transformers.

A transformer (no, not the cool toys!), formats the configuration data for the assigned storage provider. Together, the storage provider and the transformer tell the ConfAB how to read and write the data.

You can even write your own custom data store and/or transformer and use it with the same functionality.

The other major function the ConfAB provides is the storing of instance information (i.e. name, location) for each of the other blocks configuration files that are used by your application. For example, in order to implement the Data Access Application Block, you must have a configuration file that holds connection information. The ConfAB provides a configuration section in your App.config or Web.config file.

This section consists of file name, path, storage provider and transformer for each block used by your application. For example, here is an entry in the App.config file showing the settings for the Data Access Application Block(DAAB):

While you can certainly create these entries manually, Microsoft has supplied a GUI tool called the Enterprise Library Configuration Console(ELCC). This application, included with the Enterprise Library download, is an editor designed to read and write the settings for the ConfAB and the other application blocks as well.

Upon launching the ELCC, you are able to load an existing application file, app.config for desktop apps or web.config for web apps. The ConfAB will add its own sections to these files, without impacting other entries.

After loading your config file, you will see a tree-view with the word Application at the top level. The settings for this branch include the full filename of the config file you just loaded and the name of the Application, which defaults to Application. You can rename this for clarity, if you wish. Perhaps using the name of your actual application.

The next step is to add the ConfAB branch. In order to do this, you right-click on the Application branch and select New then Configuration Application Block. Note that all the blocks are listed and we will cover those choices later. Now the tree-view contains a branch labeled Configuration Application Block which contains one default branch, Encryption Settings. We will discuss the encryption options later in the article.

The next step is to choose another Application Block to implement. In our example, we will select the DAAB. In order to add the new branch, right-click on the Application branch and select Data Access Application Block. This performs two actions, first it adds a DAAB section under Application. Second, it adds additional sections under the ConfAB section. See figure 1 for an example.

Figure 1

The newly added dataConfiguration section in the ConfAB branch contains settings for both the provider and the transformer for the DAAB. The default settings are setup to use the included XML provider and transformer. If desired, you may write custom implementations for these two settings. Then you would right-click on dataConfiguration and choose New Custom to add those references.

Under the storage provider branch are the settings for the actual filename to be used for the DAAB. The default setting is dataConfiguration.config, which can be changed to suit your needs.

The other section added is the DAAB branch (Figure 2). This includes the settings for your connection string, instances and type. The default settings for database type is Sql Server. However, this can easily be changed to Oracle or another provider.

Figure 2

Within the Connection String branch are the settings for database name, server name and a true/false setting for Integrated Security. By default these are set to a generic name such as database for the database setting.

For most uses, these three settings will be sufficient to create your required Connection String. In order to accommodate additional settings, you can right-click on the Sql Connection String branch and select New parameter. This allows the addition of other settings such as User ID, password and other valid connection string settings.

By default, a configuration file is created in your application directory called dataConfiguration.config. This file can be edited manually or using the ELCC tool. See below for an example of one of these files.

There are three main nodes in this file:

1. DatabaseTypes
2. Instances
3. ConnectionStrings

Each of these sections can contain multiple entries representing multiple connections to be used.

Once the configuration settings are setup as described in the previous section, you can write some code to actually get some data. Unlike the prior releases, the DAAB now implements factories and interfaces to making your coding even easier.

There are three main scenarios for working with data in ADO.NET:

1. Retrieving updatable data in the form of a DataSet object
2. Retrieving read-only data in the form of a DataReader object
3. Executing queries which return no data, such as Insert, Delete and Update statements

We are going to use the first scenario in our examples, as it is the most common.

The first step in getting your DataSet is to create an instance of the new Database object. This object lives in the Microsoft.Practices.EnterpriseLibrary.Data namespace and represents an abstract in-memory database that commands can be run against.

In order to create this instance, we call the CreateDatabase method on the static class DatabaseFactory (see Figure 4). This takes care of all the required preparation without any input from the creator. This method will automatically read the connection string data from the configuration file created by the ELCC. If you have more than one database instance defined in your configuration, you will need to use the optional string parameter for the instance name to clarify which one to use.

The next step requires creating a DBCommandWrapper object. This object lives in the same namespace as Database. As its name implies, this object encapsulates the Command object functionality. In order to create an instance you can use one of two methods available from the Database object:

1. GetSqlStringCommandWrapper – takes a raw SQL statement
2. GetStoredProcCommandWrapper – takes Stored Procedure name and optional parameter array

Both methods perform all the functionality of preparing a command object to use as a parameter for the next method (see Figure 4).

The last step is to call the ExecuteDataSet method of the Database object. This takes a DBCommandWrapper object as a parameter. The return value for this method is a DataSet. A complete code example can be found below.

While this example represents just one implementation, there are a variety of alternate methods for getting your data the way you want it.

Once development is complete and you are ready to deploy your application, there are several issues to consider:

1. Unless the Enterprise Library dll’s are stored in the GAC, they must be distributed in the applications Bin directory.
2. While the app or web.config should be deployed just fine, the other config files, require some manual steps
3. These files must be manually copied to the application Bin directory. By default they are created in and would be deployed to the application root directory