存储分层Const数据

本文关键字：数据 Const 分层 存储 | 更新日期: 2023-09-27 18:15:03

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

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

System3 / Rules / Rule7 / ParameterXY / MaxAverageValue

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

就我所知，这可以用:

  • 非常长的常量名
    • <
  • 嵌套类/gh>名称空间

使用名称是非常丑陋的，并且它不是很好地可维护。我发现嵌套类是一种很好的方法，但是一些stylecop/fxcop规则禁止这样做，所以这在某种程度上一定是"不好的"。最后，我发现建议的替代方法(使用名称空间)也不是很好。在我看来，它创建了大量的文件夹和文件，每个文件夹和文件几乎不包含任何内容。我不喜欢在程序集反射器中出现50个子命名空间。

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

存储分层Const数据

超长常量名

这有点恶心，但至少它是可以发现的。您的所有代码将驻留在同一个地方，这样您就不会有找到它的问题。

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

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

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

名称空间

对于你所描述的问题，这是最好的处理方法。你得到每层最少的混乱，你在打字时得到智能感知，所以你可以看到你缩小到什么，而通过层次结构下降。

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

如果您确实需要大量的常量，并且将它们绑定到应用程序的其他部分没有意义，那么这是我滥用每个类一个文件和每个名称空间一个文件夹规则的罕见情况之一。你把它们塞进类里的唯一原因是。net不支持全局变量。

另一个建议

是否有这些常量所属的域特定对象?例如，是否有任何与System3 / Rules / Rule7类相关的逻辑?这难道不是你应该用它自己的类来体现的某种实际的业务规则吗?

如果你可以安排你的代码，使你有一个更厚的领域模型，那么把你的常量放在包含相应领域逻辑的类上是最合乎逻辑的。

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

每个常量在多个方法中重复使用的频率是多少?您可以考虑重新组织常数。如果您仍然发现自己有大量的常量，请尝试将它们放在具有只读属性的静态类中。

如果你只是需要一个好地方来查看它们，你也可以考虑将它们存储在app.config文件中，你可以通过AppSettings和ConfigurationManager类访问它们。

我的方法是创建一个名为Constants的密封文件。

public sealed class Constants
{
  //for e.g.
  //Sessions
  public const string APPSESSIONKEY = "AppType";
}

然后我在我的项目的其余部分使用它，这里的重要性是你将命名它，因为它将帮助你记住它，并在你需要它的时候有意义。

在你的代码中调用它。

Constants.AppSessionKey

你也可以

创建一个程序集，其唯一目的是为项目保存常数值。然后，每个其他程序集都应该引用这个程序集。遵循DRY和KISS，因为添加引用足够简单。这里的主要问题是重新编译

我们使用带有自定义T4模板的资源文件，该模板生成静态类层次结构，其中值具有只读字符串字段。

资源文件中的键用'分隔。'来构建层次结构。

我们可以将单独的资源文件编译成一个类层次结构。

我知道嵌套类是不推荐的，但在我看来，对于这种情况，它是最好的解决方案。

相关文章：