Enterprise Library : Configuration Part 1.1.2 – Transformers


No we are not talking about the Autobots and Deceptecons.  Transformers are objects that you can inject between your running code and the storage provider that reads your configuration data.  The only interface here that you have to worry about is ITransformer.

ITransformer
The ITransformer interface only has two methods, Serizlize and Deserialize which accept / return an object so you can pass any typed data that you want.  Out of the box we shipped an XmlSerializerTransformer.  As you can guess, this uses the XmlSerializer that accepts / returns the XmlNode for the XmlFileStorageProvider that ships with Enterprise Library 1.0 and turning it into the appropriate object.  We did this because we wanted a generic use across all the blocks.  Of course we could have created a transformer for each block, we just did not have the time to do this and there are some interesting problems around making it strongly typed when you have no idea how someone extended it.   Of course there is nothing stopping you from doing this .

One byproduct of using the XmlSerialzier is that the initial startup costs can be painful for some scenarios.  Now, once your app is up and running and the data has been cached, you will not see the hit over and over, but for scenarios like a smart client application where the app is constantly being brought up and down, you could find yourself wanting more.

The whole idea of a transformer is to take the data and operate on it before you use / save it.  We don’t explicitly allow for multiple transformers out of the box, yet someone out there might need it.  An interesting idea would to be to create a composite transformer that allowed for these multiple transformers.

Enterprise Library Turbo
Now another example of how to extend Enterprise Library is through the source code itself.  I know some people may not like the idea of “mucking” [very technical jargon here] around with the source code, yet it is a viable solution. One way to do this requires you install a separate tool from http://mvp-xml.sf.net.  The custom tool for Visual Studio will create a custom XmlSerializer for your object graph.  You need to download the MvpXml.Design package from http://sourceforge.net/projects/mvp-xml.  You can read more about it from Kzu here.

Another way to do this is using the extension point. Now what this does is allows you to create your own custom XmlSerializer by deriving from XmlSerialzer and not change the code.  It is pretty much the same as above, there is just a lot of work done by hand. This is discussed in this thread on The Server Side. You should contact the author because I don’t know if it has been posted to a user samples directory.

I think the coolest thing to do is combine the two methods. First get the files from the tool and compile them in a separate assembly (save the hassle of doing this by hand), then create a custom transformer that would read the data and use the right serializer based on the type and name from the custom serialzier. (The idea is from the previous thread).  One interesting thing you still have to deal with is the extensions that will be made to feed to your custom serializer.  I must admit I don’t have all the answers, but hopefully by V2 or some of you really smart folks out there will find them [answers]. 

Any blocks that you create and you care about this… I would take this approach.  I am sure with the new SGEN tool in .NET 2.0, we will be going down this path .

I wish I had really time to do all of this, but hopefully you guys have more than I do (you do want a V2 don’t you?).

What Is Next ?
I know I promised the designer next, but after a lot of feedback about transformers, I stuck this post in first. Stay tuned, the designer is coming.

This posting is provided “AS IS” with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.

Now playing: 311Amber

Comments (5)

  1. Hi Scott,

    Here is a suggestion to the Configuration block’s section classes (The classes that represents a configuration section). How about adding two methods, PreSerialize and PostDeserialize. Those methods could validate the configuration section that is going to be added or read from the configuration file. You could for example make sure the PreSerialize method will be executed before the data is going to be serialized. The PostDeserialize could be called after the section has been read, to validate the data of the section retrieved from the configuration file. Just a thought 😉

  2. Peter Hardy says:

    Hi Scott,

    Any chance you can make your tutorials available as a download.?

    Cheers, Pete

  3. Serge Shimanovsky says:

    Scott,

    I would like to see the REAL samle of how to use the config. block with MY SQL DB storage. I understand there is no default provider neither transformer (if needed?) to accomplish this. Interesting to see the example of the finished solution on this.

    Or may be you can point me out to the place where I can get one?

    Thanks, Serge

  4. Peter says:

    I’ve tried the Mvp.Xml way but I can’t figure out which classes should I set to be generated with the custom tool. I guessed they were the ‘Data’ classes, but tried with some of them (i.e., CacheManagerData) and the generated code did not compile..

    Thanks

Skip to main content