CODEWITHSUNDEEP
c#asp.netconfigurationweb-configdefault-value
Didaxis
Didaxis

Reputation: 8746

Default values: hard-code, or .config file?

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,

Upvotes: 0

Views: 2877

Answers (6)

David Savage
David Savage

Reputation: 769

I think a third option which you have not listed is to have them in a Database. There are various caching strategies you can employ to address performance concerns. The benefit of this approach is that you could host your application on one or more servers and not have it be a pain to update config changes for them.

In my experience, this has been the best approach for these cases.

Upvotes: 1

Bengel
Bengel

Reputation: 1053

Putting them in the configuration is probably the best choice. If you're looking to have a nice way to access them you can create a static class that acts as an accessor or use something like dependency injection.

Example accessor class:

public static class DefaultSupportValues
{
    public static string ProjectID
    {
        get
        {
            return ConfigurationManager.AppSettings["DefaultProjectId"];
        }
    }
}

Upvotes: 1

Chris Taylor
Chris Taylor

Reputation: 53699

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.

Upvotes: 4

Reid
Reid

Reputation: 11

First, hard-code reasonable defaults to maintain resiliency. No one likes a program which is made useless by the absence of not so strictly necessary text file.

Second, a config file is not at all an inelegant way to handle custom configuration. Depending on the environment you're deploying to, providing a gui config tool is another option. i.e. are end users going to be changing configs on thy fly? Or are sys admins going to be making planned changes?

Upvotes: 1

Erich Horak
Erich Horak

Reputation: 435

You could also store them in the database where the issue tracking data is stored.

Upvotes: 1

Oded
Oded

Reputation: 498992

Since there is no way that you know what these values should be at deployment time, you should have them in configuration. You may find it inelegant, but with values that may need to change without code changes, this is the only option.

Unless you know that deployment is fast and easy and that any code changes can be deployed quickly and without error.

Upvotes: 2

Related Questions