Fișiere de configurare a aplicației

OK, deci nu vreau să încep un război sfânt aici, dar suntem în curs de a încerca să consolidăm modul în care ne ocupăm de fișierele noastre de configurare a aplicațiilor și ne străduim să luăm o decizie cu privire la cea mai bună abordare care trebuie luată . În prezent, fiecare aplicație pe care o distribuim folosește propriile fișiere de configurare ad-hoc, indiferent dacă este vorba de fișiere de proprietăți (stil ini), xml sau JSON (utilizare internă doar în acest moment!).

Majoritatea codului nostru este Java în acest moment, deci ne-am uitat la Apache Commons Config , dar am descoperit că este destul de verbose. Am analizat, de asemenea, XMLBeans , dar se pare că o mulțime de fapturi în jur. De asemenea, simt că sunt împins spre xml ca format, dar clienții și colegii mei sunt îngrijorați să încerce altceva. Pot să înțeleg din perspectiva clientului, toată lumea a auzit de XML, dar, la sfârșitul zilei, nu ar trebui să folosească instrumentul potrivit pentru acest job?

Ce formate și biblioteci sunt utilizatorii care utilizează în sistemele de producție aceste zile, oricine altcineva încearcă să evite unghiul taxa pentru convorbiri ?

Edit: really needs to be a cross platform solution: Linux, Windows, Solaris etc. and the choice of library used to interface with configuration files is just as important as the choice of format.

0
fr hi bn
upvoted doar pentru a spune că XMLBeans "pare ca o mulțime de fals în jurul"
adăugat autor Cheeso, sursa

9 răspunsuri

XML xml XML XML. Vorbim aici fișierele de configurare aici . Nu există nici un "taxă de convorbiri unghiulare" dacă nu serializați obiecte într-o situație intensă a performanței.

Fișierele de configurare trebuie să fie citite de om și înțelese de om, în plus față de mașinile care pot fi citite. xml este un compromis bun între cele două.

Dacă magazinul dvs. are oameni care se tem de această tehnologie xml nou-încurcată, mă simt rău pentru dvs.

0
adăugat
A fost o perioadă diferită atunci ...
adăugat autor THIS USER NEEDS HELP, sursa
Nu sunt sigur dacă sarcasm, dar având în vedere că răspunsul este de 9 ani, cred că nu. :)
adăugat autor kromit, sursa

Fără a începe un nou război sfințit, sentimentele postului "taxa pe colțurile unghiulare" sunt o zonă în care eu cu mare parte nu sunt de acord cu Jeff. Nu este nimic în neregulă cu XML, este rezonabil de citit de om (la fel de mult ca fișierele YAML sau JSON sau INI), dar amintiți-vă că intenția sa trebuie să fie citită de mașini. Cele mai multe combo-uri de limbă/cadru vin cu un parser xml de un fel gratuit, ceea ce face xml o alegere destul de bună.

De asemenea, dacă utilizați un IDE bun, cum ar fi Visual Studio, și dacă xml vine cu o schemă, puteți da schema la VS și obțineți magic intellisense (puteți obține una pentru NHibernate, de exemplu).

Ușor, trebuie să te gândești cât de des te vei atinge de aceste fișiere o dată în producție, probabil că nu așa de des.

Acest lucru încă spune totul despre mine despre xml și de ce este încă o alegere valabilă pentru fișierele config (de la Tim Bray ):

"Dacă doriți să furnizați date generale despre care receptorul ar putea dori să facă lucruri neprevăzute ciudate sau nebune cu sau dacă doriți să fiți cu adevărat paranoici și pretențioși în legătură cu i18n sau dacă ceea ce trimiteți este mai mult un document decât un struct, sau dacă ordinea datelor contează sau dacă datele sunt potențial de lungă durată (ca în, mai mult de secunde), xml este calea de parcurs. De asemenea, mi se pare că combinația dintre xml și XPath lovește un loc dulce pentru formatele de date care trebuie să fie extensibile; adică este destul de ușor de scris codul de procesare xml care nu va eșua în prezența unor modificări aduse formatului mesajului care nu atinge piesa care vă interesează. "

0
adăugat
mi-aș dori să-l susțin mai mult
adăugat autor Cheeso, sursa

Din câte știu, registrul Windows nu mai este calea preferată de stocare a configurației dacă utilizați .NET - cele mai multe aplicații acum folosesc System.Configuration [1, 2]. Deoarece acest lucru este bazat pe XML, se pare că totul se mișcă în direcția utilizării xml pentru configurare.

Dacă doriți să rămâneți pe platformă, aș spune că folosirea unui fel de fișier text ar fi cea mai bună cale de parcurs. În ceea ce privește formatarea fișierului menționat, este posibil să doriți să luați în considerare dacă un om o va manipula sau nu. xml pare să fie un pic mai prietenos cu manipularea manuală decât fișierele INI datorită structurii vizibile a fișierului.

În ceea ce privește impozitul pe consola unghiulară - nu mă îngrijorează prea des, deoarece bibliotecile xml se ocupă de abstractizarea acesteia. Singura dată când ar putea fi o considerație este dacă aveți foarte puțin spațiu de stocare pentru a lucra cu și fiecare număr de octeți.

[1] System.Configuration Namespace - http://msdn.microsoft.com/en-us/library/system.configuration.aspx

[2] Using Application Configuration Files in .NET - http://www.developer.com/net/net/article.php/3396111

0
adăugat

Folosim fișiere de proprietăți, pur și simplu pentru că Java le suportă nativ. Acum câteva luni am văzut că Platforma de aplicații SpringSource utilizează JSON pentru a configura serverul și arată foarte interesant. Am comparat diferite notații de configurare și am ajuns la concluzia că xml pare să să fie cea mai bună potrivire în acest moment. Are suporturi drăguțe și este mai degrabă platformă independentă.

0
adăugat

Folosim fișiere config de stil ini. Folosim biblioteca Nini pentru a le gestiona. Nini o face foarte usor de folosit. Nini a fost orignally pentru .NET, dar a fost portat pe alte platforme folosind Mono.

0
adăugat
ini nu este definită de niciun standard și are anumite limitări pentru a fi doar un magazin cheie/valoare
adăugat autor CharlesB, sursa

Re: Comentariu epatel

Cred că întrebarea inițială se întreba despre configurația aplicațiilor pe care un administrator o va face, nu doar stocarea preferințelor utilizatorului. Sugestiile pe care le-ați oferit par mai mult pentru prefs-urile utilizatorilor decât pentru aplicația config și, de obicei, nu sunt ceva de care utilizatorul ar face vreodată direct (aplicația ar trebui să furnizeze opțiunile de configurare în UI și apoi să actualizeze fișierele). Sper că nu veți face niciodată ca utilizatorul să vizualizeze/să editeze Registrul. :)

În ceea ce privește întrebarea reală, aș spune că xml este probabil OK, deoarece o mulțime de oameni vor fi obișnuiți să-l folosească pentru configurare. Atâta timp cât organizați valorile de configurare într-o manieră ușor de folosit, atunci "taxa de convorbire unghiulară" nu ar trebui să fie prea rea.

0
adăugat

La ce platformă lucrați? Aș recomanda încercarea de a utiliza metoda preferată/comună pentru aceasta.

  1. MacOSX - plists
  2. Win32 - Registrul (sau există o nouă aici, de multă vreme când am dezvoltat pe el)
  3. Linux/Unix - ~/.apprc (nume-valoare, probabil)
0
adăugat
Întrebarea specifică acum "cross platform".
adăugat autor hippietrail, sursa

@Herms

Ceea ce am vrut să spun este să rămânem la modul recomandat, software-ul ar trebui să stocheze valori de configurare pentru orice platformă dată.

Ceea ce obțineți adesea este, de asemenea, modalitățile recomandate ca acestea să poată fi modificate. Ca un meniu de configurare dintr-un program sau dintr-un panou de configurare într-o aplicație "sistem prefs" (pentru software-urile de sistem de servicii). Nu lăsăm utilizatorilor finali să le modifice direct prin RegEdit sau Notepad ...

De ce?

  1. Utilizatorii finali (= clienți) sunt utilizați pentru platformele lor
  2. Sistemul pentru copii de rezervă poate salva mai bine setările sigure etc

@ninesided

Despre " alegerea bibliotecii ", încercați să conectați în (link-ul static) orice bibliotecă selectată pentru a reduce riscul de a intra într-o versiune-conflict-război pentru mașinile utilizatorilor finali.

0
adăugat
Argumentul pentru acest mod ar fi mult mai puternic dacă am putea găsi câteva biblioteci care oferă un API unificat diferitelor formate de fișiere de configurare.
adăugat autor hippietrail, sursa

YAML, din simplul motiv că face ca fișierele de configurare foarte ușor de citit, comparativ cu XML.

XML:


    Bob
    Abooey
    adv
    555-1212
    
[email protected]
[email protected]

YAML:

    babooey:
        computer : cpu1
        firstname: Bob
        lastname: Abooey
        cell: 555-1212
        addresses:
            - address: [email protected]
              password: xxxx
            - address: [email protected]
              password: xxxx

The examples were taken from this page: http://www.kuro5hin.org/story/2004/10/29/14225/062

0
adăugat
Kuro5hin a citat linia și numărul de caractere ca motive pentru a folosi YAML peste XML. Mă întreb de ce a uitat să citeze "numărul de instrumente și biblioteci de sprijin"? YAML: 2, XML: 2,000,000.
adăugat autor Cheeso, sursa
Yaml are mai multe biblioteci decât 2. yaml.org
adăugat autor engtech, sursa
Îmi place YAML, și aproximativ 12 limbi cu biblioteci terțe sunt listate la yaml.org. Dar singura limbă care livrează cu suport YAML implicit pare a fi ruby (din 1.9.2). Există alții? Adăugarea dependențelor poate fi un hassle.
adăugat autor nealmcb, sursa
JavaScript, România - Moldova
JavaScript, România - Moldova
328 participanți

Comunitatea Română JavaScript: github.com/js-ro Pentru confort, opriți notificările. Parteneri: @node_ro, @php_ro, @python_ro, @seo_ro, @RomaniaGroup, @ai_ro, @Grupuri_IT Offtop: @holywars_ro Joburi: @js_jobs_ro Sponsored with ❤️ by ciupacabra.com