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.
What I like to do is the following (but make sure to read to the end to use the proper type of constants):
internal static class ColumnKeys
{
internal const string Date = "Date";
internal const string Value = "Value";
...
}
Read this to know why const might not be what you want. Possible type of constants are:
const fields. Do not use across assemblies (public or protected) if value might change in future because the value will be hardcoded at compile-time in those other assemblies. If you change the value, the old value will be used by the other assemblies until they are re-compiled.
An empty static class is appropriate. Consider using several classes, so that you end up with good groups of related constants, and not one giant Globals.cs file.
Additionally, for some int constants, consider the notation:
Another vote for using web.config or app.config. The config files are a good place for constants like connection strings, etc. I prefer not to have to look at the source to view or modify these types of things. A static class which reads these constants from a .config file might be a good compromise, as it will let your application access these resources as though they were defined in code, but still give you the flexibility of having them in an easily viewable/editable space.
If these Constants are service references or switches that effect the application behavior I would set them up as Application user settings. That way if they need to be changed you do not have to recompile and you can still reference them through the static properties class.
发布评论
评论（9）
您可能可以将它们放在静态类中，并具有静态只读属性。
You probably could have them in a static class, with static read-only properties.
IMO 使用一个充满常量的类对于常量来说是很好的。如果它们偶尔会更改，我建议在您的配置中使用 AppSettings 和 ConfigurationManager 类。
当我有实际上从 AppSettings 或类似内容中提取的“常量”时，我仍然会始终有一个“常量”类来包装从配置管理器读取的内容。拥有
Constants.SomeModule.Setting总是更有意义，而不必在任何想要使用所述内容的地方直接求助于ConfigurationManager.AppSettings["SomeModule/Setting"]设定值。此设置的优点是，由于
SomeModule可能是 Constants 文件中的嵌套类，因此您可以轻松地使用依赖项注入将SomeModule直接注入到依赖于它的类中。您甚至可以在SomeModule之上提取一个接口，然后在您的使用代码中创建对ISomeModuleConfiguration的依赖关系，这样您就可以解耦对 Constants 文件的依赖关系，甚至可能使测试变得更容易，特别是如果这些设置来自 AppSettings 并且您使用配置转换来更改它们，因为这些设置是特定于环境的。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.Settinginstead of having to resort directly toConfigurationManager.AppSettings["SomeModule/Setting"]on any place that wants to consume said setting value.Bonus points for this setup, since
SomeModulewould likely be a nested class inside the Constants file, you could easily use Dependency Injection to inject eitherSomeModuledirectly into classes that depend on it. You could also even extract an interface on top ofSomeModuleand then create a depenedency toISomeModuleConfigurationin 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.我喜欢做的是以下内容（但请确保读到最后以使用正确的常量类型）：
阅读本文了解为什么
const可能不是您想要的。可能的常量类型有：public或protected）使用，因为该值将在编译时在其他程序集中进行硬编码组件。如果更改该值，则其他程序集将使用旧值，直到重新编译它们为止。static readonly字段static属性，不带setWhat I like to do is the following (but make sure to read to the end to use the proper type of constants):
Read this to know why
constmight not be what you want. Possible type of constants are:constfields. Do not use across assemblies (publicorprotected) if value might change in future because the value will be hardcoded at compile-time in those other assemblies. If you change the value, the old value will be used by the other assemblies until they are re-compiled.static readonlyfieldsstaticproperty withoutset在我看来，这是最好的方法。不需要属性，或者只读：
This is the best way IMO. No need for properties, or readonly:
空的静态类是合适的。考虑使用多个类，这样您最终会得到一组良好的相关常量，而不是一个巨大的 Globals.cs 文件。
此外，对于某些 int 常量，请考虑符号：
因为这允许 将值视为标志。
An empty static class is appropriate. Consider using several classes, so that you end up with good groups of related constants, and not one giant Globals.cs file.
Additionally, for some int constants, consider the notation:
As this allows for treating the values like flags.
另一次投票支持使用 web.config 或 app.config。配置文件是存放连接字符串等常量的好地方。我不想通过查看源代码来查看或修改这些类型的内容。从 .config 文件中读取这些常量的静态类可能是一个很好的折衷方案，因为它可以让您的应用程序访问这些资源，就像它们是在代码中定义的一样，但仍然可以灵活地以易于查看/编辑的方式显示它们空间。
Another vote for using web.config or app.config. The config files are a good place for constants like connection strings, etc. I prefer not to have to look at the source to view or modify these types of things. A static class which reads these constants from a .config file might be a good compromise, as it will let your application access these resources as though they were defined in code, but still give you the flexibility of having them in an easily viewable/editable space.
我建议使用静态只读的静态类。请找到下面的代码片段：
I would suggest static class with static readonly. Please find the code snippet below:
如果这些常量是影响应用程序行为的服务引用或开关，我会将它们设置为应用程序用户设置。这样，如果需要更改它们，您不必重新编译，并且仍然可以通过静态属性类引用它们。
If these Constants are service references or switches that effect the application behavior I would set them up as Application user settings. That way if they need to be changed you do not have to recompile and you can still reference them through the static properties class.
是的，用于存储常量的
静态类就可以了，但与特定类型相关的常量除外。Yes, a
static classfor storing constants would be just fine, except for constants that are related to specific types.