Extending the Enterprise Library

  • Article
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The latest Enterprise Library information can be found at the Enterprise Library site.

The Enterprise Library can serve as the basis for a custom library. You can take advantage of the extensibility points incorporated in each application block and extend the application block by supplying new providers. You can also modify the source code for the existing application blocks to incorporate new functionality. Finally, you can add new application blocks to the Enterprise Library. You can either develop extensions of existing application blocks and new application blocks yourself, or you can use extensions and application blocks developed by others.

Guidelines for Extensibility

Use these guidelines when you extend the Enterprise Library. You can extend the library by adding new providers, by modifying an application block's existing source code, and by adding new application blocks.

Exposing Functionality

An application block should provide a public API to expose the application block's functionality. The interface of the API should be independent of the internal implementation. Developers should not be required to understand the application block design or implementation to make effective use of its out-of-box functionality.

Whenever possible, the API should apply across common scenarios for specific functionality. Use the Configuration Console (instead of the source code) to set any values that may vary according to particular situations or users, such as names of databases or number of items allowed in a cache.

Extending and Customizing Application Blocks

An application block should provide extensibility points that let developers tailor the application block to suit their needs. The most common use of extensibility points is to allow developers to use their own providers. For example, an application block that stores data in a database should allow developers to easily add different database stores.

Developers should be able to extend an application block without modifying its source code. To accomplish this, you should add extensibility points by including public base classes or interfaces. Developers can extend the base classes or implement the interfaces and then add their extensions to the application block by modifying the configuration file. With this approach, there is no need to modify or rebuild the application block. Developers interested in extending the application block should find that it is well-organized, comprehensible, and conforms to Microsoft patterns & practices guidance.

When defining the set of extensibility points, consider the effect on usability. A large number of extensibility points can make the application block complicated to use and difficult to configure.

Some developers may be interested in customizing the code, which means that they will modify the source code instead of using the extension points. To support this effort, the application block design should provide the following:

  • It should follow object-oriented design principles whenever practical.
  • It should use appropriate patterns.
  • It should efficiently use resources.
  • It should adhere to security principles—for example, distrust of user input and principle of least privilege.

For specific guidance about coding styles and naming conventions for the .NET Framework, see Design Guidelines for Class Library Developers on MSDN. A helpful tool when developing application blocks is FxCop. This is a code analysis tool that checks .NET Framework managed code assemblies for conformance to the Microsoft .NET Framework design guidelines. To download FxCop, see the FxCop Team Page on GotDotNet.

Embodying patterns & practices

It is important to remember that the Enterprise Library is only a small part of Microsoft patterns & practices. An Enterprise Library application block should embody any other relevant patterns & practices guidance, including, for example, the guidance in Application Architecture for .NET: Designing Applications and Services on MSDN.

Including Instrumentation

An Enterprise Library application block should include instrumentation that enables developers, testers, and system administrators to monitor application block behavior and performance. The amount of instrumentation depends on the application block functionality. There needs to be enough instrumentation to provide developers, testers, and system administrators with sufficient information to ensure that the application block is working as designed and performing acceptably.

Using Loose Coupling

If one Enterprise Library application block requires another Enterprise Library application block to perform a task, then, where possible, the interdependent application blocks should be loosely coupled so that users can replace one of the application blocks with their own implementations. If possible, use the pluggable-provider model. It isolates the code with the dependencies into a provider that can be changed to a different provider.

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The latest Enterprise Library information can be found at the Enterprise Library site.