ConfigurationPropertyCollection是否需要是静态的

本文关键字：静态 是否 ConfigurationPropertyCollection | 更新日期: 2023-09-27 17:59:01

根据这篇经常被引用的文章《解开.NET配置之谜》，在实现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存储并初始化为非静态完全可以？

ConfigurationPropertyCollection是否需要是静态的

但它并不能解释为什么s_properties字段需要是静态的，

s_properties之所以是静态的，是因为you开发人员只需要一组应用程序的配置属性，即一个单一实例。[这可能被认为是典型的。]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; }
}

作者假设您应该只有一个CCD_ 7的实例。

那么，是否存在直接访问静态字段的"隐藏"访问权限？

不确定我是否理解这个问题。

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

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

[带有其他编辑的原件]]
否。[Static]ConfigurationXXX对象不是连续创建、处置和重新创建的。像所有静态对象一样，公共静态初始值设定项/构造函数只执行一次——第一次调用该对象。例如，当我调用以下内容时：

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

执行静态ConfigurationManager类构造函数。由于这个类是静态的，它将在执行它的当前AppDomain的生存期内生存。

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

相关文章：