Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Seven Microsoft Application Blocks in One Neat Little Package : Page 2

Microsoft's Enterprise Library is a configurable and extensible software library that consists of seven integrated application blocks. Get a close look at all the goodies inside this powerful package.


advertisement

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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap