Enterprise Library : Configuration Part 1
As Peter Provost says to me all the time “it is all about configuration, that is what it [Enterprise Library] essentially is…”. I guess he is right. Since Enterprise Library [EntLib] is built to be extensible, pluggable, etc., we needed a mechanism to allow for these requirements. The default Configuration system in the .NET framework allows you read configuration from your application config file (app.config / web.config), yet it provides no mechanism for any other storage and it works with IConfigurationSectionHandler instances which may not be rich enough for your requirements. Enterprise Library doesn’t try and replace this functionality but rather give you another option if you need it that fills some of the requirements from Enterprise customers that we (patterns & practices) have identified.
Configuration is separated into two separate physical and logical concepts : Runtime and Design-time. I will attempt to explain these things at a high level and then in future posts drill down on the individual concepts in more detail. So forgive me if I start to high, don’t worry we will reach terminal velocity pretty soon.
Runtime
The runtime version of configuration is where the bulk of the work happens. There are three concepts going on here, meta-data configuration, storage and transformation. Meta-data configuration is the term we use to describe the configuration information that will express a blocks particular configuration requirements. Storage allows for reading and writing your configuration and transformation allows you to transform the data from storage into a specific format.
In a normal configuration file it would look something like the following:
1: <?xml version="1.0" encoding="utf-8" ?>
2: <configuration>
3: <configSections>
4: <section name="someName" type="someType" />
5: </configSections>
6: <appSettings>
7: <add key="MyKey" value="MyValue" />
8: </appSettings>
9: </configuration>
We have added our own IConfigurationSectionHandler that allows us to define the meta-data configuration. Here is what your configuration will look like when you add any library from Enterprise Library :
1: <?xml version="1.0" encoding="utf-8" ?>
2: <configuration>
3: <configSections>
4: <section name="enterpriselibrary.configurationSettings"
5: type="Microsoft.Practices.EnterpriseLibrary.Configuration._
6: ConfigurationManagerSectionHandler,Microsoft.Practices._
7: EnterpriseLibrary.Configuration" />
8: </configSections>
9: <enterpriselibrary.configurationSettings
10: xmlns:xsd=https://www.w3.org/2001/XMLSchema
11: xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
12: xmlns="https://www.microsoft.com/practices/enterpriseli_
13: brary/08-31-2004/configuration">
14: <configurationSections>
15: <configurationSection name="ApplConfig1">
16: <storageProvider xsi:type="XmlFileStorageProviderData"
17: name="XmlStorage" path="myconfig.xml" />
18: <dataTransformer xsi:type="XmlSerializerTransformerData"
19: name="XmlTransformer" />
20: </configurationSection>
21: </configurationSections>
22: </enterpriselibrary.configurationSettings>
23: <appSettings>
24: <add key="MyKey" value="MyValue" />
25: </appSettings>
26: </configuration>
Now you can see that we have our own namespace in here that define your configuration settings (meta-data configuration). The configurationSections element now allows you to define specific named configurationSection elements that contain the meta-definition of your configuration.
The first thing you will notice is the storageProvider element. This is the storage provider you define that reads and/or writes data to a physical storage location (for example a file). The next thing is the dataTransformer element. This is the transformer you define to take data from storage and format to the specification for your application and then take the data from the application and format it so the storage provider can save the data back to the physical store. The transformer is not required, you can just have the object returned from the storage provider returned directly to your application (for example, a DataSet).
In summary (and at a high level), the runtime enables you to have configuration for your application that does not tie you to just your app.config file. Now those that have been paying attention will notice that I am of the opinion that xml is not a programming language but just self describing storage . I know that some of you are saying, wow you mean I have to start typing all this xml goop (a very technical word) by hand for my applications? Well I am glad you asked, and the answer is a resounding no. You can still edit by hand, but that is no longer necessary
.
Design-time
The design-time configuration infrastructure is two fold : the library to help you build the plug-ins for the tool and the tool itself. Before we go to far, the following is a picture of the tool:
You can call this a meta-data editor (I took this picture on a Win2K3 box without themes). As you can see we have a few blocks in here : Caching, Configuration and Data. All the tool knows how to do is look for an assembly level attribute and load your design-time editor into itself. This is where the design-time library helps you out. It gives you the base classes and helpers to wire all your designers up using a good portion of the System.ComponentModel namespace. The tool works similarly to the MMC console and can be used by developers and operators in your organization. We were hoping to have an integrated environment for Visual Studio, but of course we have to stop sometime and ship the thing… so stay tuned for that in V2.
As they say, pictures speak a thousand words, so I will leave the design-time for now.
I hope these little blog postings will help everyone get comfortable with using EntLib. Stay tuned for the next posting where we will be drilling down into the internals of the Configuration Runtime….
Now playing: Queens of the Stone Age - No One Knows