Guidelines for Extending 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.

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. Use the guidelines in this topic when you extend the Enterprise Library.

There are three ways to extend the Enterprise Library. You can write custom providers, modify an application block's source code, or write a new application block. If you choose to extend the Enterprise Library, keep the following recommendations in mind:

  • The application block should expose its functionality so that developers can use the application block without modifying it.
  • The application block should be easy to extend and modify.
  • The application block should embody Microsoft patterns & practices guidance.
  • The application block should include instrumentation.
  • The application block should be loosely coupled with other application blocks.

Note

You can add new application blocks to the Enterprise Library, or you can use extensions and application blocks developed by others. For information about creating new application blocks, see the Application Block Software Factory at the patterns & practices Community Site on CodePlex.

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 add different database stores easily.

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 code-analysis tool checks .NET Framework managed code assemblies for conformance to the Microsoft .NET Framework design guidelines. To obtain FxCop, see the Code Analysis page on MSDN.

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. This model isolates the code dependencies within a provider. Users can then change this to a different provider when required.