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
 

Creating Custom Providers for Enterprise Library

When the providers installed with Enterprise Library don't meet your needs, take advantage of the library's pluggable architecture and roll your own.


advertisement
ne of the most useful features of the Microsoft Enterprise Library is its adaptability; all the application blocks are fully extensible. Like ASP.NET itself, Enterprise Library implements a pluggable architecture that lets you replace parts of the code with your own implementations or extend the application blocks by creating your own providers. Figure 1 shows a schematic view of how the application blocks rely on services exposed by the Enterprise Library core (such as configuration, instrumentation, and object creation services). In addition, each block uses one or more pluggable providers to connect to the resources or data it uses or processes. About The Caching Application Block
As an example of this architecture within an application block, Figure 2 shows how the Caching Application Block uses a series of separate classes to cache and expose data. The core operations of the block take place through a Cache Manager, which exposes the public methods available to client applications. Cached data resides in an in-memory cache, providing best performance when reading and storing data. At the same time, all changes to the cached data are passed to a backing store provider, which persists the data onto a more permanent medium.

 
Figure 1. Pluggable Architecture: The Enterprise Library architecture uses replaceable (pluggable) providers.
 
Figure 2. Pluggable Architecture Details: The Caching Application Block uses a series of separate classes to cache and retrieve data.
The backing store provider is an example of pluggable code. The Caching Application Block ships with three different backing store provider implementations.
  • The Isolated Storage provider encrypts data and stores it on disk within the current user's profile folders.
  • The Database Backing Store provider stores it in a database table.
  • The Null Backing Store provider does not store the cached data in a persistent format, so that the caching mechanism relies only on the in-memory cache—an approach that meets some types of caching requirements.
My previous articles about using Enterprise Library in ASP.NET applications showed how to use the Isolated Storage provider—mainly because this is the easiest to configure and suffices to demonstrate the Caching Application Block interface. While Isolated Storage is a good choice for many desktop applications, it's definitely not an ideal technique for ASP.NET server-based applications. In ASP.NET, all anonymous users execute the application under the same account, so Isolated Storage has no way to differentiate between users. In addition, data encryption and the storage location make Isolated Storage data difficult to share across multiple servers in scenarios such as a Web farm.

One way around this is to use a central database server, and configure the Caching Application Block to persist its data there, using keys that include a user ID and an application name, or other information that identifies each application or user where this is a requirement (some data you cache may, of course, be common to all users). But using a central database server is not ideal for all applications—and that's where pluggable architecture enters the picture. If the shipped backing store providers don't meet your needs, you can create a custom backing store provider that persists the data in exactly the way that best suits your requirements.



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap