In this example, I am using the XML File Storage Provider to save my configuration settings in my sitesettings.config file and using the default storage provider for caching, called the NullBackingStore, which stores the cache information into a Hashtable in memory.
This time when I run the Enterprise Library Configuration tool I need to add both the Caching Application Block and Configuration Application Block to my application (shown below). I keep the default settings, but I do have to specify that sitesettings.config will be the XML file to store my global application settings. If you don’t do this, the application will toss an error reminding you to do so.
At first I was a bit confused as to why there is an XML File Storage Provider and XML Serializer Transformer under cachingConfiguration. I didn’t add it. It turns out that there is a separate XML file, called by default cachingConfiguration.config, created to store the caching configuration information. It specifies that I am using the NullBackingStore as well as a few other settings.
Here is the code that reads and writes to both the configuration file and cache for testing:
Although the configuration settings might be a bit ugly in the backend, the code is pretty straight forward. I have added comments above so you can see what is happening. Here are the configuration files:
As you can see, there is certainly a lot of flexiblity with the Enterprise Library as literally you could change the configuration in the backend to specify different storage providers and theoretically never change a single line of code. There has got to be some price to this flexiblity, which is a couple of XML files to specify settings. It looks a bit daunting at first if you aren’t used to XML and the plug-in type architecture, but by playing with it more and more one can get comfortable with it pretty quickly.