何时使用常量与配置文件来维护配置

我经常和自己争论是否要在我的web.config或Constants.cs类中放置某些键或类似的东西。

例如，如果我想存储应用程序特定的键（无论大小写），我可以将其存储并通过自定义键从Web配置中获取它，或者通过在我的常量类中引用一个常量来使用它。

您何时要在配置键上使用常量？

这个问题确实适用于我认为的任何语言。

就个人而言，我只会将常量用作默认值，并让它们被配置文件中的值覆盖。

如果应用程序使用命令行参数，则这些参数将依次覆盖配置文件参数。

配置文件中的值比常量类中的值更难维护，因为编译器不检查它是否存在并且类型正确，IDE通常不为其提供代码帮助，并且因为这是您必须切换到的另一种语法在编程时。

所以我建议把：

• 在所有安装中，值都将与代码中的常量相同。将它们放在一个常量类中（您可以轻松地尝试各种值以查看它们的工作方式）并将它们放入使用它们的模块中有一些好处（在修改该模块时不必打开另一个文件，避免一个人都可以编辑的文件导致版本控制冲突。
• 每次安装（配置）需要更改（可能）的值。而且您可能仍然想将default放入代码中，因此，如果未在配置中设置该值，则应用程序仍将（以某种方式）工作。

更改常量需要在大多数情况下重新构建应用程序。换句话说，当某人无法访问代码时，常量将保持不变。

因此，最终用户需要提供（和需要更改）的任何信息都应放在配置文件中。其他大多数都需要接受常量。但是，如果配置文件损坏，则必须有合法的默认值或错误异常处理。

不属于对象抽象的元素（即，如果不打算由外部（调用）对象修改的常量很可能被隐藏，并且本质上意味着它们比配置文件更适合作为私有常量）。

当有许多配置元素属于不同的对象，彼此之间不相关，并且有那么多的对象需要提取（相同或自己的）配置文件时，这些东西本来应该是常量。

一个简单的经验法则是在知道要使用一组固定的值时创建常量，这些值可以应用于任何给定的上下文而无需更改；为其他所有内容提供外部配置。

常量的一个很好的例子是，您使用的所有形状都可以是SQUARE或ROUND。在大多数语言中，只需分配一次并优化访问方式，就可以利用该值不会随时间变化的事实。

当您需要动态获取值时需要进行外部配置，因为您无法预先假定要使用的值，但这并不意味着您必须进行任何性能折衷：对于配置值，您期望目前，只要做得正确，您只需为检索它们一次付出代价，并且仍然可以获得所有好处。

您也可以简单地使用以下设计模式：“约定之上的配置”。

http://msdn.microsoft.com/zh-CN/magazine/dd419655.aspx http://en.wikipedia.org/wiki/Convention_over_configuration

根据定义，常量是一个不应更改的值（例如PI）的存储位置。

我认为您的意思是“参数”而不是常数

除了已说明的内容外，请注意，将变量暴露给配置文件中的用户输入可能会损害应用程序。

如果可能，请不要在未通过代码验证其完整性的情况下在配置文件中公开这些值。另外，我建议您不要在配置文件中放置业务规则参数（例如最高薪水等），也不要对这些参数使用常量。此类值应使用适当的表定义存储在数据库中，以便在更改它们时加强某些安全性，并且可以自动创建数据值的版本（使用存储的proc或db日志）。当然，这取决于您的应用程序的敏感程度。

如果曾经使用配置文件存储数据，请确保对它们进行版本控制。