he problem with developing enterprise applications is you have to reinvent the wheel for each key area, such as configuration, database access, or security. Microsoft has addressed this problem in the past by providing application building blocks. However, one of the biggest problems with these application blocks was they were not very well integrated with each other. So, Microsoft’s Pattern & Practices Group has released the Enterprise Library, a large configurable and extensible software library that consists of seven integrated application blocks.

You may already be familiar with the individual application blocks that the Enterprise Library contains (like the Data Access Application Block), but it also offers some new ones (like the Cryptography Application Block). Table 1 describes the application blocks within the Enterprise Library.

Figure 1. The Enterprise Library’s Graphical Configuration Tool

The Enterprise Library offers the following benefits:

• You can use the Enterprise Library as the basis for your own application blocks by using its extensible (provider-based) development model and the graphical configuration tool, the Configuration Console (see Figure 1).
• Through its standard interfaces, you can customize the Enterprise Library to suit your development.
• The Enterprise Library ships with the entire source code, which you can alter without any restrictions.
• You can use each application block as a standalone. You need only reference the Configuration Application Block to use any of the others in the Enterprise Library.
• The Enterprise Library consists of several hundred pages of documentation, samples, and walkthroughs that teach you about the architecture and design of extensible application frameworks.

Configuration Made Easy

The Enterprise Library ships with the Configuration Console (see Figure 1), a graphical user interface (GUI) through which you can configure your applications and the Enterprise Library itself. So you don’t have to directly edit large, complicated XML configuration files to make changes. This support enables administrators to make configuration changes as well as developers, because they don’t need to know anything about the XML structure of configuration files.

Each application block provides a set of several interfaces called providers that allow you to extend the Enterprise Library’s functionality in various ways. For example, you can extend the Caching Application Block with a user-defined backend storage provider, which defines where you want to store cached data in your application. Such a user-defined provider also can be configured through the Configuration Console.

The Design of the Enterprise Library

To consolidate existing application blocks into one library, Microsoft had to make some critical design decisions. One such decision was that no application block should have a dependency on another, except the Configuration Application Block. Figure 2 shows the relationship between the application blocks.

Figure 2. Relationship Between the Application Blocks

This design enables you to use each application block on its own. As I previously mentioned, the only requirement is a reference to the Configuration Application Block. The reason for this is that each application block has configuration files that must be maintained (through the Configuration Console). Furthermore, the Enterprise Library has an assembly called Common that also must be referenced within your solution. This assembly provides functionality that each application block uses. Cryptography functionality is also implemented in this assembly. So you don’t have to use the Cryptography Application Block when you want to encrypt settings in a configuration file.

Extensibility Points and Custom Application Blocks

Each application block is based on a provider model, where you can extend the library in several ways. You also can plug in your own custom application block. When you write components or providers to extend the Enterprise Library, you must follow a simple set of predefined policies so that you don’t break any of Microsoft’s design implementations. The first policy is that each application block should contain a very simple API with which the developer can interact. This API should be designed in a way that it is independent from the internal implementation. In other words, when you change something within your own application block, the public API should not change.

Another very important policy is that each application block should provide extensibility points (based on providers) where you can plug in your own functionality. The Security Application Block, for example, offers some providers where you can choose and define where your security objects (users, roles) are stored. The Enterprise Library provides a provider for a database or for Active Directory as well. If you are storing users and roles in a LDAP directory, you can implement your own provider and configure and use it through the Enterprise Library.

When you integrate your own application block into the Enterprise Library, you should also equip it with logging and instrumentation code. You also should provide some meaningful performance counters since each application block provides some performance counters that can be monitored through the Performance monitor.

If your own application block needs functionality from another application block, consider decoupling the connection points between the two blocks. You can use a provider-based model to achieve the necessary decoupling between the components. This way, you give developers the chance to replace external dependencies with their own functionality and features.

When you have to store configuration information, use the Configuration Application Block. Your own application block will depend on this application block anyway. Also, the Configuration Application Block is very configurable and extensible. You can use the Configuration Console to configure all the necessary aspects and settings throughout your application.

Compiling the Enterprise Library

Because the Enterprise Library ships with source code, you must compile it to use it. The compilation can be started automatically during installation. All assemblies and tools are placed in the C:Program FilesMicrosoft Enterprise Libraryin directory. From this directory, you can reference any assembly you need in your project. The Enterprise Library provides two ways to compile the assemblies after installation: a batch file and a Visual Studio .NET 2003 solution. If you want to build it with batch files, you have three options:

• BuildLibrary.bat: compiles the whole Enterprise Library with all needed tools
• CopyAssemblies.bat: copies the newly compiled assemblies in the bin directory
• InstallServices.bat: installs Windows Services, which the Logging and Instrumentation Building Block needs

The other option, a Visual Studio .NET 2003 solution, provides the build configurations described in Table 2.

All assemblies created through the build process are unsigned. Therefore, they don’t have strong names. So you can’t place them into the Global Assembly Cache (GAC) for common sharing purposes. If you want to do this, you must sign them with your own provided key.

Integrated, Configurable, and Extensible

Each application block within the Enterprise Library is very well integrated with the others, enabling you to combine them in a very efficient way. You also can extend the Enterprise Library with your own providers or implement your own application block, which you can seamlessly integrate into the Enterprise Library as well.