I often fight with myself on whether to put certain keys in my web.config or in a Constants.cs class or something like this.
For example if I wanted to store application specific keys for whatever the case may be..I could store it and grab it from my web config via custom keys or consume it by referencing a constant in my constants class.
When would you want to use Constants over config keys?
This question really applies to any language I think.
Personally I would only use constants as default values, and let them be overridden by values from a configuration file.
If the application takes command line arguments, then those would in turn override the configuration file parameters.
Value in configuration file is harder to maintain than value in constants class, because the compiler does not check it exists and is of correct type, the IDE usually does not provide code assistance for it and also because it's yet another syntax you have to switch to while programming.
So I would suggest putting:
Changing Constants require re-building the application most of the cases. Put other way, constants remains constants when someone doesn't have an access to code.
So any information that end user need to provide (and need to change) should go in the configuration files. Most others need to go under constants. However, there must be legitimate defaults or error exception handling if the configuration files are broken.
Elements which are not part of the abstraction of the object (i.e if constants which are not meant to be modified by external (calling) objects are likely to be hidden and essentially mean they would be better off as private constants than config files.
When there are many config elements which pertains to different objects, not related to each other, and when so many objects needs to pull out (same or their own) config files, chances are that these things should have been constants.
You can also simply use this design pattern: "convention over configuration".
http://msdn.microsoft.com/en-us/magazine/dd419655.aspx http://en.wikipedia.org/wiki/Convention_over_configuration
A simple rule of thumb is to create constants when you know you'll work with a fixed set of values which you know can be applied for any given context without needing to change; provide external configurations for everything else.
A good example of constants would be if all the shapes you worked with could either be SQUARE or ROUND. In most languages, you'll be able to leverage the fact that this value doesn't change over time, by allocating it only once and optimizing how it's accessed.
External configurations are necessary when you'll need to retrieve the value dynamically because you cannot assume in advance the value you'll be working with, but that doesn't mean you have to make any performance tradeoff: for configuration values you expect to be present, when done correctly, you only pay the price of retrieving them once and still get all the benefits.
A constant by definition is a memory location for a value that should not change (such as PI).
I assume you meant 'parameter' and not a constant
In addition to what have been said, note that exposing variables to user input from config file may harm the application.
When possible, don't expose values in config file without validating them in code to have a sanity check. Also, I suggest that you don't place business rules parameters (such as max. salary, etc.) in config files and don't use constants for those either. Such values should be stored in database with the appropriate table definitions so that some security is enforced when they are changed and you could automatically create versions of the data values (using stored procs or db logs). Of course, this depends on how sensitive your application is.
If you ever use config files to store data, make sure you version them.
xsdtool to generate one from the other) and use the config withXMLSerializer(most sensible way to handle XML in C# anyway), so you can validate in advance, but it's still some extra work. – Jan Hudec Nov 23 '11 at 08:10