Using XML to Share Constants Across ProjectsBy Rachael Schoenbaum
XML is the new "buzz" word out there being bandied about by bigwigs and top execs, but what does it mean for you as the developer? How can you use XML in your applications to produce code that is both faster to produce and easier to modify? This article highlights a case where using XML helped cut down on development time and made modification of the application a snap. (For information on what, exactly, XML is, be sure to read: What is XML?, and check out the XML FAQs section.)
I was working on a project that had a library of code (a compiled DLL) and a Web front end that leveraged the DLL. I had constants that both applications used and didn't want to try and maintain two separate constants files for each application. The pain involved in making sure changes were made to both files was too high. In addition, the constants I was using would have to be changed every time I deployed the applications since they differed in the development environment, the staging environment, and the production environment. Compiling the constants into the DLL would make deployment a big hassle. I needed a way to share the constants across both applications and make deployment simple.
Why Not Use Web.Config for Constants?
In Specifying Configuration Settings in
Web.config, author Scott Mitchell looks at storing configuration information, like database connection strings, in the Web application's
Web.configfile. Initially I considered using
Web.configas a place to store my constants, but decided against it for the following reasons:
Web.configcauses the Web application to restart, thus slowing down changes that need to be rolled out.
- Values in
Web.configare all stored as strings, making the storage of different and more complex types difficult or impossible.
- While values can be shared between
Web.configand the DLL, the only way to test the DLL is through the Web context. This methodology requires a recompile and re-deploy for every change, which is a huge hassle. (At my company, we often build stand-alone WinForms applications to test the DLL.)
XML to the Rescue
Web.configwas not ideal for my situation, I came up with the idea of using XML to store my constants in a manner similar to the way
Web.configdoes. I chose to use XML as the constants repository since, being a text file, it made changes very easy to incorporate, whether they were additions or modifications. Too, XML can be created quickly and easily with any text editor, is human-readable, and can be annotated via comments (
<!-- comments -->).
Below is a sample XML configuration file:
Accessing the Constants
Defining and populating an XML file is all well and good, but I needed a way to access the values. In my first attempt, I was hitting the XML file directly every time someone requested a constant. This made the class really slow (file IO is a time consuming process) and I wanted it to be faster. Then I came across the
Cacheobject, which provides access to the .NET Framework data cache. Because the
Cacheobject allows you to make objects dependant on files, it was the perfect solution. The dependency ensures that any changes made to the XML file will force the
Cacheentry to be dropped. (For more information on caching XML files, read Scott Mitchell's article Displaying Cached XML Data in a DataGrid, and Intelligently Refreshing the Data; for general information on cachiing in an ASP.NET Web application, see Scott McFarland's article, Caching with ASP.NET.)
I created a class,
ConstantsManager, to provide read access to the constants.
The class checks to see if the
Cache has an entry for the constant in question. If so, it returns that
entry. If not, it looks for the entry in the XML file and stores it in the
Cache for future use. If
the entry doesn't exist in the
Cache or XML file, it returns a 0.
Reading the Constants from the Web Application
To retrieve a constant value from the XML constants store, I just added a reference to the compiled code that has the
ConstantsManagerclass in it. Because it's a public class with shared members, you don't have to instantiate a new object to use the methods. The following code shows an example of reading the
DB_CONNconstant from the constants class:
To create constants for a Web application, simply create a file called
applicationConstants.config that lives
in the root directory of the Web site. That's all there is to it!
|Protecting Your Constants|
Since the constants XML file will likely contain sensitive data, such as database connection strings, it is vitally
important that the constants XML file cannot be accessed by an anonymous Web visitor. To protect against this, I gave
my XML constants file a |
Pros, Cons, and Ideas for Improvement
After having used this XML configuration file technique in numerous Web applications at my company, I've identified a number of pros and cons for this approach, as well as some ideas for improvement. What I really like about this approach includes:
- Changes are automatic and don't require a recompile – deployments to multiple environments are easier, as is maintaining the code.
- The constants file can be shared in both the testing DLL and the Web application – recall that my company uses a separate DLL for testing purposes. With this approach, you don't have to hard-code constants into the DLL - both the DLL and the Web application can share the same constants store.
- Return value is data type specific – the class returns integers or strings, depending on the value of the tag. While it wasn't necessary in my case to store Booleans, dates, longs, doubles, etc, it would be fairly easy to extend the class to return these or other data types.
- File is only accessed the first time a constant is requested – Because the values are stored in the data cache, the XML file is only accessed the first time a new constant is requested. This improves performance since file IO tends to be slow.
Along with advantages of this system, I have found a shortcoming. The structure of the XML file is fairly rigid. That is, the code expects each XML tag to have no attributes and no nested or children tags. This limits the structure of the XML and your configured constants to flat values. This is a nice segue into the ideas for improvements.
Along the lines of the first con, one of the ways this concept could be expanded or improved would be to allow the XML file to allow more flexible data descriptors i.e., "groups" of constants that logically belong together like the 50 states and their abbreviations or the possible member types in the system. Such a grouping would also allow for versioning. That is, you could group constants by application version, with an XML file like:
Another possible enhancement would be to have the
ConstantsManager load all constant values from the
XML file into memory when the Web application loads. Restarting the application or making changes to the XML file
would make the application recompile take longer than normal, but all the values in the XML file would be
immediately available via memory and the file would be accessed as infrequently as possible.
|An Update for this Article is Available!|
About a month after publishing this article, I updated the |
In this article I introduced a means to store constants for a Web application using a single XML file. The advantage of this approach is that you can store an entire Web application's constants in a single, easy to read and easy to edit XML file. This is useful when you have a single Web application that requires different constants when in different locations, such as when the Web application is on the production server versus when the Web application is on a development server.
The constants from the XML file can be easily accessed via the
ConstantsManager class, which caches the
constant results in the .NET data cache to improve performance. I have been using this constant-storing technique
at my company for some time now, and invite you to do the same. If you have any questions, feedback, or recommendations,
please don't hesitate to contact me.
About the Author
Rachael Schoenbaum is a developer specializing in ASP and VB.NET, ASP/Visual Basic, SQL Server, XML, and related technologies. She consults for Lucidea and has been programming since 1999.