Nincs ConfigurationPropertyCollection kell statikus?

szavazat
3

E szerint a leggyakrabban idézett cikk, feltárása a Mysteries of .NET Configuration végrehajtása során a ConfigurationSection / ConfigurationElement, javasoljuk, hogy ezt a mintát követi:

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; }
}

De ez nem magyarázza meg , hogy miért a s_propertiesterületen kell lenniük statikus és tulajdonságait inicializálni egy statikus konstruktor.
Elvégre ez csak keresztül érhető el a nem statikus Propertiesfelülírt ingatlan ...

(Van egy bonyolult sor egyéni konfiguráció-menedzsment, ez jelentősen leegyszerűsíti a dolgokat, amelyek a s_propertiesterületen nem lehet statikus ...)

Szóval, van néhány „rejtett” hozzáférés közvetlenül a statikus mágneses tér? A Configuration***tárgy folyamatosan teremtett, és újra létre, oly módon, hogy objektum szintű területeken elvész, és mint ilyen, nem hatékony?
Vagy ez tökéletesen tárolására és inicializálja a ConfigurationPropertyCollectionnem-statikus?

A kérdést 12/06/2011 13:45
a forrás felhasználó
Más nyelveken...                            


1 válasz

szavazat
2

De ez nem magyarázza meg, hogy miért a s_properties területén kellene lennie statikus,

Az ok s_propertiesstatikus azért van, mert akkor a fejlesztő csak akart egy készlet - egyelem¶ fokon - a konfigurációs tulajdonságokat egy alkalmazás. [ És ez tekinthető tipikus .] A ConfigurationXXX (ConfigurationManager, például) osztályok statikus, mert akkor csak szükség egy per AppDomain.

Alapvetően a minta:

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; }
}

A szerző feltételezve, hogy csak egyetlen példánya s_properties.

Szóval, van néhány „rejtett” hozzáférés közvetlenül a statikus mágneses tér?

Nem biztos, hogy kövesse ezt a kérdést.

A Configuration *** objektum folyamatosan teremtett, és újra létre, oly módon, hogy objektum szintű területeken elvész, és mint ilyen, nem hatékony?

[Edit: Attól függ ... Gondoltam rá, hogy a ConfigurationManager. De, mondjuk azt akartam, hogy egy helyi másolatot a AppSettingsCollection. Azt, hogy egy statikus csak olvasható mező nyilatkozatot. Az összefüggésben szakaszok, stb Aztán lenne még egy statikus mező inializer, jóllehet static Dictionary<string, ConfigurationPropertyCollection> Properties. A végén, még mindig azt hiszem, hogy te mindig csak szeretnénk, ha egyetlen esetben tulajdon beállításainak gyűjtemény. ]

[Eredeti más [ módosításokat ]]
No. [ Statikus ] ConfigurationXXX objektumok nem folyamatosan létrehozott, ártalmatlanítani, és újra létre. Mint minden statikus tárgyak, a public static inicializáló / kivitelező lefut egy alkalommal - az első alkalom, hogy a tárgy neve. Például, amikor hívom a következő:

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

A statikus ConfigurationManagerosztály konstruktor kerül végrehajtásra. Mivel ez az osztály statikus, hogy élni fog az élettartama a jelenlegi AppDomain, amelyben végre.

Én nem ajánlom inicializálása app tartomány tulajdonságai, konfigurációs tulajdonságok, illetve ingatlan gyűjtemények vagy azon belül egy példányát osztályban. Amikor a program végrehajtása megkezdődik, akkor hivatkozhat egy statikus Configuration osztály, amelyben meg kell csomagolni, és testre interakció ConfigurationXXX osztályok tagjai, és funkciókat.

Válaszolt 12/06/2011 14:04
a forrás felhasználó

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more