存储分层Const数据

Question

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

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

System3 / Rules / Rule7 / ParameterXY / MaxAverageValue

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

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

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

使用名称非常难看,而且它的维护性也不是很好.我发现嵌套类是一种很好的方法,但是一些stylecop/fxcop规则禁止这样做,所以这在某种程度上肯定是"坏"的.最后,我发现建议的替代方案,使用命名空间,并不是非常好.Imho它创建了大量的文件夹和文件,每个文件夹和文件几乎都没有.我不喜欢在装配反射器中弹出50个子命名空间.

那么..你是怎么做这种任务的？你会建议什么？

Answer 1

很长的常量名称

这有点恶心，但至少是可以发现的。您的所有代码都将驻留在同一位置，因此查找它不会有问题。

我发现嵌套类是一个很好的方法，但是一些 stylecop/fxcop 规则禁止这样做，所以这在某种程度上一定是“坏”的

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

这很糟糕的最重要​​原因是，嵌套类应该在面向对象的依赖意义上强关联，以便布局在逻辑上有意义。除了一些罕见的情况（例如枚举器类）之外，在所有情况下它都没有意义。在您的情况下，它也没有意义，因为您的类根本没有任何行为或面向对象 - 它们只是常量的层次结构。

命名空间

对于你所描述的问题，这是最好的处理方法。每个级别的混乱程度最少，并且在打字时可以获得智能感知，这样您就可以在向下浏览层次结构时看到正在缩小的范围。

恕我直言，它创建了大量的文件夹和文件，每个文件夹和文件几乎不包含任何内容

如果您确实需要大量常量，并且将它们绑定到应用程序的其他部分没有意义，那么这是我滥用每类一个文件和一个-folder-per-namespace 规则。您甚至将它们填充到类中的唯一原因是因为 .Net 不支持全局变量。

另一个建议

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

如果您可以安排代码以便拥有更厚的域模型，那么放置常量的最合乎逻辑的位置就是体现相应域逻辑的类。

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