ConfigurationManager.AppSettings Prestasie Kommer

Question

Ek is van plan om te wees die stoor van al my konfigurasie-instellings in my aansoek se app.config afdeling (met behulp van die ConfigurationManager.AppSettings klas).As die gebruiker verander instellings met behulp van die jeug se UI (kliek op die blok, die keuse van radio knoppies, ens.), Ek is van plan om die skryf van die veranderinge aan die AppSettings.Op dieselfde tyd, terwyl die program loop ek is van plan om toegang tot die AppSettings voortdurend van'n proses wat sal voortdurend die verwerking van data.Veranderinge aan instellings via die UI nodig het om te invloed op die verwerking van data in real-time, wat is die rede waarom die proses sal wees om toegang tot die AppSettings voortdurend.

Is dit'n goeie idee met betrekking tot prestasie?Met behulp van AppSettings veronderstel is om te wees "die regte manier" om te slaan en toegang konfigurasie-instellings toe te skryf .Net die programme, maar ek is bekommerd dat hierdie metode was nie bedoel is vir'n konstante lading (ten minste in terme van die instellings om voortdurend te lees).

As iemand ondervinding met hierdie, ek sal dit baie waardeer die insette.

Update: Ek moet seker verduidelik'n paar punte.

Hierdie is nie'n web-program, sodat die koppeling van'n databasis om die aansoek kan wees overkill net vir die berging van konfigurasie-instellings.Dit is'n Windows Vorms aansoek.

Volgens die MSDN documention, die ConfigurationManager is vir die berging van nie net aansoek vlak instellings, maar die gebruiker-instellings as goed.(Veral belangrik as, byvoorbeeld, die aansoek is geïnstalleer as'n gedeeltelike-trust aansoek.)

Update 2: Ek aanvaar lomaxx se antwoord, want Properties wel lyk soos'n goeie oplossing, sonder om by te voeg enige bykomende lae my aansoek (soos'n databasis).Wanneer die gebruik van Eienskappe, is dit reeds doen al die kas wat ander voorgestel.Dit beteken dat enige veranderinge en die daaropvolgende lees is al gedoen in die geheue, maak dit baie vinnig.Eienskappe skryf slegs die veranderinge aan die skyf wanneer jy uitdruklik vertel om dit te.Dit beteken ek kan maak veranderinge aan die konfigurasie-instellings op-die-vlieg op die loop van die tyd en dan net doen'n finale red uit te skyf wanneer die program verlaat.

Net om te bevestig dit sou eintlik in staat wees om te hanteer die las wat ek nodig het, ek het'n paar toetse op my laptop en in staat was om te doen 750,000 lees en 7,500 skryf per sekonde met behulp van Eienskappe.Dit is so ver bo en buite wat my aansoek sal ooit selfs kom naby aan die behoefte wat ek voel baie veilig in die gebruik van Eiendomme sonder om die impak prestasie.

Answer 1

sedert jy 'n Winforms app, al is dit in net 2.0 daar is eintlik 'n stelsel gebruikers instellings (genoem Properties) wat ontwerp is vir hierdie doel. Hierdie artikel oor MSDN het 'n goeie inleiding in hierdie

As jy nog steeds bekommerd oor prestasie neem dan 'n blik op SQL Compact uitgawe wat soortgelyk is aan SQLite maar is die Microsoft offer wat ek gevind speel baie mooi met Winforms en daar is selfs die vermoë om maak dit werk met Linq

Answer 2

Check uit SQLite, dit lyk soos 'n goeie opsie vir hierdie spesifieke scenario.

Answer 3

Dylan,

Moenie die aansoek config lêer vir hierdie doel, gebruik 'n SQL DB (SQLite, MySQL, MSSQL, wat ook al), want jy sal moet minder bekommerd wees oor concurrency probleme tydens lees en skryf na die opstelling lêer.

Jy sal ook 'n beter buigsaamheid in die tipe data wat jy wil stoor. Die artikel appSettings is net 'n sleutel / waarde lys wat jy kan ontgroei met verloop van tyd en as die jeug verval. Jy kan gebruik persoonlike config afdelings, maar dan is jy in 'n nuwe probleem area wanneer dit kom by die ontwerp.

Answer 4

Die appSettings is nie regtig bedoel vir wat jy probeer om te doen.

Wanneer jou .NETTO aansoek begin, dit lees in die app.config lêer, en caches die inhoud daarvan in die geheue.Vir daardie rede, nadat jy skryf die app.config lêer, jy sal moet een of ander manier dwing om die runtime om te re-parse die app.config lêer, sodat dit kan die kas van die instellings weer.Dit is onnodig

Die die beste benadering sou wees om te gebruik om'n databasis te stoor jou konfigurasie-instellings.

Behalwe die gebruik van'n databasis, wat jy kan maklik die opstel van'n eksterne XML-konfigurasie lêer.Wanneer jou aansoek begin, jy kan die kas sy inhoud in'n NameValueCollection voorwerp of HashTable voorwerp.As jy verander/voeg instellings, sou jy doen dit aan dat cached kopie.Wanneer jou aansoek gesluit, of op'n gepaste tyd interval, kan jy skryf die inhoud van die cache terug te dien.

Answer 5

Iemand korrek my as ek verkeerd is, maar ek dink nie dat AppSettings tipies is bedoel om gebruik te word vir hierdie tipe van konfigurasie-instellings. Normaalweg sou jy net sit in instellings wat redelik staties bly (databasis verband snare, lêer paaie, ens). As jy wil aanpas gebruikers instellings op te slaan, sou dit beter wees om 'n aparte voorkeure lêer te skep, of verkieslik stoor die instellings in 'n databasis.

Answer 6

Ek sou nie gebruik konfigurasielêers vir die stoor van gebruikers data. Gebruik 'n db.

Answer 7

Kan ek vra waarom jy nie instellings die gebruiker se is die redding van 'n databasis?

In die algemeen, ek red aansoek instellings wat baie selde verander in die afdeling appSettings (die standaard e-pos adres fout logs word gestuur na die aantal minute waarna jy outomaties uitgeteken, ens) Die omvang van hierdie is regtig by die aansoek, nie aan die gebruiker, en is oor die algemeen gebruik word vir ontplooiing instellings.

Answer 8

'n ding wat ek sou kyk na doen is caching die appsettings op 'n lees, dan spoel die instellings van die kas op die skryf waarin die bedrag van die werklike lading die bediener het om te gaan met vir die verwerking van die appSettings moet verminder.

Ook, indien moontlik, kyk na die breek van die appSettings up in configSections sodat jy kan skryf en kas verwante instellings te lees.

Dit alles gesê, ek wil ernstig oorweeg om na stoor hierdie waardes in 'n databasis as jy lyk eintlik die stoor voorkeure , en nie aansoek instellings.