CODEWITHSUNDEEP
c#resourcesconstantsembedded-resource
user1688603
user1688603

Reputation: 121

Resource Dictionary Vs .cs file

I have some constants that i would like to have at application level, like stored procedure names, user messages, and others. there is very less chance that i will ever change these resources.

Please let me know what is good practice for keeping constants in our application.

Is Resource dictionary is preferable over .cs file.

Regards AA

Upvotes: 3

Views: 595

Answers (1)

bopapa_1979
bopapa_1979

Reputation: 9237

For starters, you're on the right track thinking about this stuff at all. Magic strings and other magic values are bad for lots of reasons.

Here are some guidelines we use:

  1. Constants are only allowed for things that are REAL-WORLD constant. If you need to use "My bonnie lies over the {0}" as a format string, you use a RESOURCE for that.
  2. Things that might change, EVER, are not constants. You have a few options for this stuff.
  3. If it isn't part of your logic, it doesn't go in source code. It goes in one of the following externals locations and gets referenced in source code so that you don't have to recompile to make a change.

We generally have three files per assembly, as needed: First, a constants file. This is usually as simple as Constants.cs. Put your constants (AND readonly statics that are not compile-time constant and never change) in this file. You could also include things that are configurable but MUST have a default value.

internal class Constants
{
    public const LogLevel DEFAULT_LOG_LEVEL = LogLevel.Error;

    public static readonly string APP_NAME = Configuration.ApplicationName ?? "Test Application";
}

Second, a file that reads configuration values and returns them as static values. This is generally Configuration.cs and is responsible for return ALL configuration values. This saves you from having to recompile to change a connection string, deal with a setting, or something else. The actual values reside in places like an .ini file, web.config or app.config, database table, or other location outside the source code. If the following example you could smatter ConfigurationManager.AppSettings["ApplicationName"] all over your code, but then what if you want to change the key of that appsetting? You have to find an rename all the reference to it. Just take the extra 30 seconds to do something like this, and all Configuration.ApplicationName.

internal class Configuration
{
    public static string ApplicationName
    {
        get
        {
            return ConfigurationManager.AppSettings["ApplicationName"];
        }
    }
}

Finally, one or more resource files. This is where we put things like icons, images, unusual fonts, localized (or just changable) strings for display purposes, etc...

There is no specific right way do do this stuff, but I think the above will give you a place to start.

Upvotes: 3

Related Questions