我经常想知道正确的方法：
例如，在我的程序中，我有大约100个常量（或枚举）用于某些计算。它们最好存放在一个地方。它们可以按层次结构分组，例如：
System3 / Rules / Rule7 / ParameterXY / MaxAverageValue
当然，我希望在编码时可以访问这些值，因此将它们存储在某种资源中并不是一种选择。
据我所知，这可以通过以下方式完成：
使用名称非常难看，而且它的维护性也不是很好。我发现嵌套类是一种很好的方法，但是一些stylecop / fxcop规则禁止这样做，所以这在某些方面肯定是“坏的”。最后，我发现建议的替代方案，使用命名空间，并不是非常好。 Imho它创建了大量的文件夹和文件，每个文件夹和文件几乎都没有。我不喜欢在汇编反射器中弹出50个子命名空间。
那么..你是怎么做这种任务的？你会建议什么？
答案 0 :(得分：4)
非常长的常数名称
这有点严重，但至少它是可以发现的。您的所有代码都将驻留在同一位置，因此您无法找到它。
我发现嵌套类是一种很好的方法，但是有些stylecop / fxcop规则禁止这样做，所以这在某种程度上肯定是“坏”
这是一个很糟糕的原因，因为自动代码生成/代码检查工具更难以使用。另一个原因是用Intellisense发现它们更难。
这个问题最重要的原因是因为嵌套类应该在面向对象的依赖性意义上强烈关联，因为布局在逻辑上是有意义的。除了一些罕见的情况（例如Enumerator classes），它都没有意义。在你的情况下它也没有意义，因为你的类根本没有任何行为或面向对象 - 它们只是常量的层次结构。
命名空间
对于您描述的问题，这是处理它的最佳方法。每个级别的杂乱程度最低，并且在输入时可以获得智能感知，这样您就可以在层次结构中降序时看到正在缩小的内容。
Imho它创建了大量的文件夹和文件，每个文件夹和文件几乎不包含任何内容
如果你真的需要一个庞大的常量池，将它们绑定到应用程序的其他部分是没有意义的，那么这是我滥用单文件的罕见情况之一class和每个命名空间的一个文件夹规则。你甚至将它们填入课堂的唯一原因是因为.Net不支持全局变量。
另一个建议
您是否拥有这些常量所属的特定于域的对象？例如。是否有与System3 / Rules / Rule7类相关的逻辑？这不是某种实际的商业规则，你应该用它自己的类来体现吗？
如果您可以安排代码以便拥有a thicker domain model，那么放置常量的最合理的位置就是体现相应域逻辑的类。
如果拥有一个厚域是没有意义的，那么你有完全通用的规则处理，并且你依靠常量来提供业务引擎逻辑，那么你就拥有了一个数据驱动的应用程序。这意味着您应该将数据存储在配置文件中，而不是代码中。
答案 1 :(得分：1)
每种常数在多种方法中重复使用的频率是多少？您可以考虑重新组织常量。如果您仍然发现自己拥有大量常量，请尝试将它们放在具有只读属性的静态类中。
如果您只是需要一个好地方在一个地方查看它们，您还可以查看将它们存储在app.config文件中，您可以通过AppSettings和ConfigurationManager类访问它们。
答案 2 :(得分：0)
我这样做的方法是使用一个名为Constants的密封文件。
所以
public sealed class Constants
{
//for e.g.
//Sessions
public const string APPSESSIONKEY = "AppType";
}
我在项目的其余部分使用这个，这里的重要性就是你要命名的内容，因为它会帮助你记住它并在你需要的时候有意义。
在你的代码中调用它。
Constants.AppSessionKey
你也可以
创建一个程序集，其唯一目的是保存项目的常量值。然后，每个其他大会都应参考这一个。在DRY和KISS之后，因为添加引用很简单。这里的主要问题是重新编译。
答案 3 :(得分：0)
我们使用带有自定义T4模板的Resources文件，该模板生成一个静态类层次结构，其中包含值的只读字符串字段。
我们的资源文件中的键用'。'分隔。建立层次结构。
我们可以将单独的资源文件编译成一个类层次结构。
我知道不建议使用嵌套类，但在我看来，对于这种情况，这是最好的解决方案。