ConfigurationPropertyCollection 是否需要是静态的？

Question

根据这篇经常引用的文章Unraveling the Mysteries of .NET Configuration，在实现 ConfigurationSection / ConfigurationElement 时，建议遵循以下模式：

private static ConfigurationPropertyCollection s_properties;
static ExampleSection()
{
        // Predefine properties here
        // Add the properties to s_properties
}

/// Override the Properties collection and return our custom one.
protected override ConfigurationPropertyCollection Properties
{
    get { return s_properties; }
}

但它没有解释为什么s_properties 字段需要是静态的，并且属性需要在静态构造函数中初始化。
毕竟，它只能通过非静态的Properties 覆盖属性访问...

（我有一套复杂的自定义配置管理，它会大大简化 s_properties 字段不是静态的事情......）

那么，是否有一些直接访问静态字段的“隐藏”访问？ Configuration*** 对象是否会不断地创建和重新创建，从而导致对象级字段丢失，从而导致效率低下？
或者将ConfigurationPropertyCollection 存储和初始化为非静态是否完全可以？

Answer 1

但它没有解释为什么 s_properties 字段需要是静态的，

s_properties 是静态的原因是因为你开发人员只想要一个应用程序的配置属性集——一个单例实例。 [这可能被认为是典型的。] ConfigurationXXX（例如，ConfigurationManager）类是静态的，因为每个 AppDomain 只需要一个。

基本上，在示例中：

private static ConfigurationPropertyCollection s_properties;
static ExampleSection()
{
        // Predefine properties here
        // Add the properties to s_properties
}

/// Override the Properties collection and return our custom one.
protected override ConfigurationPropertyCollection Properties
{
    get { return s_properties; }
}

作者假设您应该只有一个 s_properties 实例。

那么，是否有一些直接访问静态字段的“隐藏”访问？

不确定我是否遵循这个问题。

Configuration*** 对象是否不断创建和重新创建，从而导致对象级字段丢失，从而导致效率低下？

[编辑：取决于...我正在考虑配置管理器。但是，假设我想要我的 AppSettingsCollection 的本地副本。我会将其设为静态只读字段声明。在 Sections 等的上下文中，我仍然会使用静态字段初始化器，尽管是 static Dictionary<string, ConfigurationPropertyCollection> Properties。最后，我仍然相信您只需要一个属性设置集合的实例。]

[与其他 [编辑] ]
不会。[静态] ConfigurationXXX 对象不会持续创建、处置和重新创建。像所有静态对象一样，公共静态初始化器/构造器只执行一次 - 第一次调用该对象。例如，当我调用以下命令时：

string someValue = ConfigurationManager.AppSettings["SomeKey"];  

静态ConfigurationManager 类构造函数被执行。由于此类是静态的，因此它将在执行它的当前 AppDomain 的生命周期内存在。

我不建议将应用程序域属性、配置属性或属性集合初始化为 或在 实例类中。当您的程序开始执行时，您应该依赖一个静态 Configuration 类，您可以在其中包装和自定义与 ConfigurationXXX 类、成员和函数的交互。