Refaktorizace konfiguračních souborů – kudy do toho? rubrika: Návrh
6
dond
Řeším(e) problém s nabobtnalou a nepřehlednou konfigurací (XML, cca desítka souborů, multiplatformní desktopová aplikace, Java, část slouží jako prohlížečka / editor dat, část řídí procesy přes vzdálená volání). Jsme nuceni konfiguraci zamrazit (tj. další změny budou muset být zpětně kompatibilní) a dostali jsme čas na její „refaktorizaci“.
Aktuální konfigurace obsahuje předpisy pro vzhled, jakous-takous internacionalizaci, definici příkazů (např. co se kde volá po kliknutí na tlačítko), informace pro připojení na servery, uživatelské informace (zárodky přístupových práv, role) a popis chování prostředí (např. klávesové zkratky, viditelnosti prvků apod.). Jde řádově o tisíce řádek v XML (≤10k).
Cílem je konfigurační soubory zjednodušit, zpřehlednit, použít nějaký referenční mechanizmus (tj. zabránit opakování stejných konstrukcí na více místech).
Nevíme, kudy do toho: všechno souvisí se vším a vytvořit nějaký cílový model „vzorové“ konfigurace se nám dosud nepodařilo, vždycky se zasekneme na nějaké části s otázkou typu „bude možné tohle použít i XYZ?“, na kterou obvykle nedokážeme rozumně odpovědět, protože XYZ jsme zatím neřešili.
Máte někdo s něčím podobným nějakou zkušenost?
Anonym
Začal bych rozdělením konfiguračních informací do balíků podle určení. Dále si stanovil typy konfiguračních dat. Některá mohou být slovníková (typicky překlady), některá popisující chování (business rules), čistě konfigurační (SERV_XYZ_IP = 1.2.3.4) atd. Pro jednotlivé balíky a typy dat pak způsob ukládání.
Dále to pak závisí na architektuře. Může to být bez připojení k síti nebo ne? Jsou to údaje, jichž aktualizace je nutná okamžitě nebo ji lze odložit na nějakou synchronizaci?
Příklad - změním oprávnění k nějakému zdroji - to je okamžitá změna nutná pro přístup z jakéhokoliv klienta, DB/LDAP ideální kandidát.
Příklad - změním label/barvu tlačítka - XML je můj kamarád a synchro pomoci nějakého aktualizačního threadu/při spuštění klienta.
Příklad - vlastní uživatelská nastavení - tady záleží na možnostech aplikace, jestli má cestovní profily nebo ne. Pokud ano, DB/LDAP. Pokud ne XML nebo INI.
Příklad - kurzovní listek - načtu při startu aplikace, držím v memory cache, threadem kontroluji zda nedošlo ke změně stavu, dle potřeb aktualizuji, aktuální držím někde na serveru v centrální DB.
Mezi těmito zdroji pak bridge, které udrží vazby.
Dále pak důsledně v programovém kódu dodržovat naplnění defualtními hodnotami, aby pokud budou nastaveny všechny kritické hodnoty - URL/IP/users apod. aplikace byla schopna fungovat i bez např. překladu, barevné palety apod.
Je to na dlouhé rozepisování:)
Pro zobrazení všech 5 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře