I’m working on an issue-tacking application, where website users enter issues which are sent over a WCF service to an administration console, where support agents begin handling the issue.
As issues come over the wire, they are grouped by a projectID and a categoryID
All issues coming from a specific website, should have the same default Project and CategoryID’s.
Problem:
It is unknown at this point, what those default values should be since projects and categories are entered by support agent managers sometime in the future within the admin console. (None of this is yet deployed, and a meeting between myself and the support team to hammer out these details is unlikely)
Question:
What is the best way to handle these default values? What I’ve considered so far:
1) Hard-code them. The problem with hard-coding, is that it will be difficult to change the values after deployment.
2) Stick em’ in a .config file. This is flexible, and will allow things to be changed easily after deployment, but I hardly think it’s elegant (or at least it just feels that way to me)
If you’ve had any similar experiences, or just good insight and advice, I’d love to hear it! Thank you,
You might even consider going one step further and storing your defaults in the database. This will provide flexibility of configuration and centralized management of those defaults.
Personally, the approach I might often take is to have my configuration in code, but have the ability to override the defaults by supplying new values in the configuration file or in the Db. Why do I go this far? Well this way I can deploy with minimal configuration and then provide overrides if and when required.