Zitat von
Jens Hartmann:
Bei dem Programmablauf, frag ich halt nicht die
DB ab, sondern direkt die Komponenten. Wenn das ja so OK wäre, muss ich das ja eigendlich nur noch alles von INI auf
DB umstellen, und fertig. Die frage, die ich mir gestellt habe, war allrdigs, ob das so in Ordnung ist.
warum sollte das nicht ok sein, ich mache das genauso, bei mir steht die Settingsklasse mit den einzelnen Settings zwischen der INI-Datei/Registry und der Anwendung, die Anwendung sollte garnicht direkt auf eine Datei zugreifen. Wenn ich dann noch beim Create angebe, welches TEdit zuständig ist, brauche ich das Konfigurations-
GUI nur noch zu zeichnen, die Werte stehen dann beim Start automatisch drin und werden auch dort wieder geholt und zurückgespeichert. Allerdings habe ich beim Lesen noch einen Mode-Parameter eingeführt, der angibt, ob der Wert direkt aus dem Setting genommen wird, ob vorher der neueste Wert aus der INI geholt wird und ob der geholte Wert ins TEdit übernommen werden soll. Braucht man aber nicht oft, weil das Setting-Objekt immer den aktuellen Wert hat und sich an der INI eigentlich nichts ändern kann, es sei denn, jemand schreibt hintenrum manuell was rein und es muss sofort übernommen werden - finde ich eher sinnlos.
Wo das Zeug physikalisch gespeichert wird, sollte man so flexibel wie möglich handhaben (ich unterstütze z.B. auch unixartige Home-Verzeichnisse), weil sich das abschliessend sowieso nicht entscheiden lässt: wer MS-hörig ist MUSS die Registry verwenden, INI-Dateien sind transparenter, werden aber vom MS abgelehnt. Datenbanken sind eigentlich zu aufwendig dafür und
XML biete auch keine besonderen Vorteile. Ich finde die Tatsache, dass bei Datenbanken die Feldgrösse i.a. festgelegt ist, eher hinderlich, und man muss wohl boolean, integer, real usw. als Strings speichern, wenn man nicht gleich alles als Variant deklarieren will. Das ist allerdings in einer INI auch nicht anders, nur mit freier Stringlänge.
Gruss Reinhard