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 https://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 https://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 https://www.microsoft.com/info/cpyright.htm .