 |
(Edward Moemeka) A popular pattern for application design and development is to use offline files to persist configuration information so that downstream users can modify certain properties associated with an application without requiring rebuild activities like SDLC. When I was a Java Architect for Sun MicroSystems, the Properties file was the prescribed approach to do this. Although it offered some flexibility, it certainly was not ideal for many situations, especially those requiring hierarchical structures. With the advent of .NET, Microsoft opted for the much more robust and powerful extensible markup language as the underlying mechanism for storage of the offline configuration parameters. This works out great. XML is a perfect solution for such scenarios. It’s relatively simple to implement, fast, yet manages to be still very powerful, extensible, and flexible.
As great as XML is however, there are some shortcomings. In the case where the configuration file is a custom one defined outside the realm of the canned configuration files like app.config or web.config by Microsoft, the problem of schema validation and synchronization can be an added headache, especially since they are generally an unnecessary effort. What I mean is, these tasks have nothing to do with the actual configuration of the application but tend to be thought about a lot. In the case of the canned config files, there is a general lack of intuitive comprehension to the config file formats. One simply has to know how to configure a WCF service for instance. There is no notion of being able to intuitively configure one from scratch without knowledge of the spelling and casing of every word/character typed. I must admit that you are helped along in many regards with the intellisense engine which seems to be built atop of schema specifications, but I found that for the canned config files it was still not adequate, and for the custom ones I didn’t want to have to write a schema for my ocnfiguration. |
