c# - 存储分层 Const 数据

Question

我经常想知道这样做的正确方法:

例如，在我的程序中，我有大约 100 个常量(或枚举)用于某些计算。它们最好存放在一个地方。它们可以按层次分组，例如:

System3 / Rules / Rule7 / ParameterXY / MaxAverageValue

当然，我希望在编码时可以访问这些值，因此将它们存储在某种资源中并不是一个真正的选择。

据我所知，这可以通过以下方式完成:

• 非常长的常量名
• 嵌套类
• 命名空间

使用名称非常难看，而且不太好维护。我发现嵌套类是一种很好的方法，但一些 stylecop/fxcop 规则禁止这样做，所以这在某种程度上一定是“坏的”。最后，我发现建议的替代方案，使用 namespace ，也不是很好。恕我直言，它创建了大量的文件夹和文件，每个文件夹和文件几乎什么都不包含。而且我不喜欢在程序集反射器中弹出 50 个子命名空间。

那么..你是如何完成这种任务的？你有什么建议？

Answer 1

very long constant names

这有点恶心，但至少它是可以被发现的。您的所有代码都将位于同一个位置，因此您可以轻松找到它。

I find nesting classes a nice way to do it, but some stylecop/fxcop rules forbid that, so this must be "bad" in some way

它不好的一个原因是自动代码生成/代码检查工具更难使用。另一个原因是使用 Intellisense 更难发现这些。

这是不好的最重要的原因是因为嵌套类应该在面向对象的依赖感中强关联，以使布局在逻辑上有意义。除了极少数情况(例如 Enumerator classes )，在所有情况下都没有意义。在您的情况下，它也没有意义，因为您的类根本没有任何行为或面向对象 - 它们只是常量的层次结构。

Namespaces

对于你描述的问题，这是最好的处理方式。每个级别的困惑情况最少，并且您在键入时会获得 Intellisense，这样您就可以在层次结构中下降时看到您正在缩小范围。

Imho it creates masses of folders and files that each contain almost nothing

如果你真的需要一个巨大的常量池，并且将它们绑定(bind)到应用程序的其他部分没有意义，那么这是我滥用一个文件一个的罕见情况之一 -类和每个命名空间一个文件夹的规则。您甚至将它们塞进类中的唯一原因是因为 .Net 不支持全局变量。

另一个建议

您是否有这些常量所属的特定于域的对象？例如。是否有任何与 System3/Rules/Rule7 类相关的逻辑？这不是您应该在自己的类中体现的某种实际业务规则吗？

如果你可以安排你的代码，那么你有 a thicker domain model , 那么放置常量最合乎逻辑的地方就是在包含相应领域逻辑的类上。

如果拥有一个厚域没有意义，您拥有完全通用的规则处理，并且您依靠常量来提供您的业务引擎逻辑，那么您就有了一个数据驱动的应用程序。这意味着您应该将数据存储在配置文件中，而不是代码中。