Extending and Modifying Enterprise Library

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. For detailed information about creating providers and extensions for each application block, see the "Extending and Modifying" topic in the sections of this documentation for each of the blocks. For general information about creating custom providers, and integrating with the configuration tools, see Creating Custom Providers for Enterprise Library.
• Modify the source code of an application block. For more information about the design of each block, see the topic "Design of the Application Block" in the sections of this guidance devoted to each of the application blocks.
• Write a new application block. You can use the existing blocks as guidance to create a completely new block. You will also find additional information and resources on creating and extending the blocks on the Enterprise Library community contributions site at https://www.codeplex.com/entlibcontrib/.

The following sections explain some of the factors to keep in mind when extending or modifying Enterprise Library.

Guidelines for Extending Enterprise Library

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.

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 use resources efficiently.
• 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 Microsoft Application Architecture Guide, 2nd Edition 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.

Guidelines for Modifying the Application Blocks

The Enterprise Library application blocks were designed to be used in a variety of applications and to provide general-purpose facilities and capabilities. Using the extension points, you can adapt the application blocks to suit the needs of any particular application. However, if, instead, you want to add new features to an application block, you can do so by modifying the source code (the application block ships with both the source code and the binaries). In this case, consider the following guidelines and best practices:

• Make sure you understand how the application block works by reading the relevant section of the documentation.
• Consider changing the application block's namespace if you alter the code significantly or if you want to use your customized version of the application block along with the original version. Note that changing the application block's namespace requires you to update all other application blocks and applications that reference the modified application block to incorporate the new namespace.
• Use strong naming. A strong name allows the assembly to be uniquely identified, versioned, and checked for integrity. You will need to generate your own key pair to sign your modified version of the application block. For more information, see Strong Naming the Enterprise Library Assemblies. Alternatively, you can choose to not sign your custom version. This is referred to as weak naming.
• You must recompile your code for your modifications to take effect. Open the Visual Studio solution file for the application block and rebuild the entire solution.