IMO using a class full of constants is fine for constants. If they will change semi-occasionally I recommend using AppSettings in your config and the ConfigurationManager class instead.
When I have "constants" that are actually pulled in from AppSettings or similar I still will always have a "constants" class that wraps the reading from configuration manager. It's always more meaningful to have Constants.SomeModule.Setting
instead of having to resort directly to ConfigurationManager.AppSettings["SomeModule/Setting"]
on any place that wants to consume said setting value.
Bonus points for this setup, since SomeModule
would likely be a nested class inside the Constants file, you could easily use Dependency Injection to inject either SomeModule
directly into classes that depend on it. You could also even extract an interface on top of SomeModule
and then create a depenedency to ISomeModuleConfiguration
in your consuming code, this would then allow you to decouple the dependency to the Constants files, and even potentially make testing easier, especially if these settings come from AppSettings and you change them using config transformations because the settings are environment specific.