我有一个Common项目，其中添加了我的QueryStringNames的公共常量。
通常常量应该是内部或私有的，但在这里我需要公共常量，因为我想允许全局访问查询字符串名称、会话密钥等。
我知道有3种解决方案，但它们都有一个重要问题。调用者程序集将包含我的常量副本，这意味着如果我必须更改常量值，我将不得不编译我的Common程序集和调用者程序集！
1) public const string ConstName = "a value";
2) public readonly string ConstName = "a value";
3) To be stored in a public resource file.
除了将公共常量存储在没有 IntelliSense 的 web.config 文件中，还有什么最好的方法来定义 C# 中的公共常量？
const就可以了。否则，请使用static readonly字段。
const将被嵌入到调用程序集中，而static readonly仅包含对该字段的引用。这意味着当更改值时，const需要重新编译所有相关代码，而public readonly即使没有重新编译调用程序集也可以使用新值。static。对于配置值，我会使用某种单例模式，最好是IoC变体，而不是Class.Instance变体。所以我只需定义如下的接口：interface IMyConfig
{
string Key{get;}
}
并且需要让需要此配置的类将其作为构造函数参数：
public MyClass(IMyConfig config)
{
...
}
<appSettings>
<add key="myconstant" value="here's the value!" />
</appSettings>
以下是引用该值的类，可提供智能感知、便于未来轻松更改且无需重新编译。
public class MyAppConfigSettings
{
public string MyConstant { get; private set; }
public MyAppConfigSettings()
{
MyConstant = ConfigurationManager.AppSettings["myconst"];
}
}
这可能不是解决方案的答案，但它可能会给你一些其他的想法。
NameValueCollection 或类似的东西，而不是从静态的 AppSettings 属性中获取。然后通过 IoC 进行注入。 - CodesInChaosNameValueCollection来传递它。保持松散耦合。如果您需要针对配置类编写单元测试（我不知道为什么要这样做，因为没有任何逻辑可供测试），您可以提供一个接受NameValueCollection的第二个构造函数。不过我认为那会有点过了。 - Jeff LaFayMyAppConfigSettings 的实例。唯一构造 MyAppConfigSettings 的代码应该是 IoC 容器。我说的不是测试配置类，而是测试依赖于配置类的类。使用不同的配置进行测试对我来说听起来很标准。 - CodesInChaospublic class MyService
{
// injected dependency
public IMyConstants MyConstants { get; set; }
public MyMethod(){
// get your query...
var query = IMyConstants.Query;
}
}
public MyConstants : IMyConstants {
// implementation of query property from the myservices.dll interface
public string Query { ... }
}
Constant这个名称，因为配置值并不是真正的常量。如果它真的是一个常量，我们就不需要在这里使用DI了。 - CodesInChaos如果您正在启用 fxCop（Visual Studio 发行版中包含的代码分析工具），您可能会收到建议将常量更改为：
这样可以提高代码的可读性和维护性。public static readonly string ConstName = "a value";
static readonly确实很有意义。当使用const时，只有隐式的static，而使用readonly时则不然。 - CodesInChaos如前所述，情境并不相同：
当字段声明包括 readonly 修饰符时，对于由声明引入的字段的赋值只能作为声明的一部分或在同一类中的构造函数中进行。