Konzept: Klasse / Entity für Einstellung der Software

[internet]

Hallo,

ich überlege derzeit, wie ich innerhalb einer Web-Applikation "Einstellungen" in der Datenbank speichern kann, sodass ich von der GUI darauf zugreifen kann und diese aktivieren / deaktivieren kann.

Sowas wie hier:

Um nun nicht 1000 Properties in eine Tabelle aufzunehmen, möchte ich das dynamisch halten, sodass für jede Setting es einen Datenbankeintrag gibt.

Mir schwebt dazu folgendes Konzept vor:
Eine Datenbank - Tabelle anlegen:

ApplicationSetting
- ID
- uniqueName (bspw: "resetPassword")
- dataType (String, Integer, Double Boolean) -> Typ wird als String - Wert gespeichert...
- valueString
- valueInteger
- valueDouble
- valueBoolean

Um die verschiedenen Datentypen zu speichern, lege ich eben verschiedene Felder an für String, Double usw.

Erweitern könnte man das u.a. noch
a) mit einer XML, welche beim Start der Applikation ausgelesen wird und die Werte dann gespeichert werden
b) Weitere Datenbank - Tabelle ApplicationSettingGroup (um die Settings zu gruppieren)

Ich würde nun gerne wissen, ob das Konzept so passt oder was man besser machen könnte?

 

[kneitzel]

Also ich handhabe es meist so, dass ich Werte als String speichere. Also ähnlich, wie es ja auch in einer Properties Datei als String hinterlegt ist.

Das wird ja nur einmalig gelesen und da spielt das Parsen der Werte keine Rolle.

 

[internet]

Ok, also du hast dann quasi nur:

ApplicationSetting
- ID
- uniqueName (bspw: "resetPassword")
- value

Value ist dann vom Typ String / Varchar?
Und wie wandelst du das dann später in den richtigen Datentyp um (boolean, Date, Double... )?

 

[kneitzel]

Die Frage ist, wie Du es genau modellieren willst. Ich sehe hier gerade zwei Möglichkeiten.

Die erste Möglichkeit ist das, was wir derzeit in der Regel haben:

Wir haben feste Konfigurationen. Also da wird nichts dynamisch dazu kommen. (Das dürfte ja der Standard sein). Das bedeutet, dass wir eine Klasse haben, in der die Konfiguration ablegen. Sprich: Da sind dann Getter / Setter zu finden. Da wollen wir auch immer alles haben und die haben dann die Typen, die wirklich benötigt werden, also int, String, LocalDateTime, double, Integer, Double, ...

Damit wir nicht immer wieder irgendwas neu schreiben müssen, erbt die Klasse von einer ConfigBase Klasse. Diese hat dann im Kern eine einfache Properties Instanz.
Dazu gehören dann viele Funktionen wie:
- Laden / Speichern der Werte. Das kommt meistens aus Dateien, aber das kann prinzipiell alles sein. Wie geladen / gespeichert ist, ist in einem ConfigAdapter festgelegt, d.h. neue Quellen sind einfach hinzu zu nehmen.
- Parsen / Prüfen / in String schreiben Methoden. Also das sind dann einfache Methoden wie
int getIntProperty(final String key, final int default)
void setIntProperty(final String key, final int value)

In der Config Klasse, die wir dann schreiben, haben wir dann
a) eine Konstante für den key: public static final string KEY_SOME_VALUE = "some.value";
b) ggf. einen Default Wert, der genommen wird, wenn der key nicht vorhanden ist: public static final int DEFAULT_SOME_VALUE = 1;
c) dann kommen getter / setter, die aber einfach aufgebaut, da eigentlich nur protected Methoden aufgerufen werden... dann ist da also einfach im Getter etwas wie return getIntProperty(KEY_SOME_VALUE, DEFAULT_SOME_VALUE);

Damit schreiben wir derzeit unsere Config-Klassen.

Das wäre mein Ansatz. Da betrachte ich die Datenbanktabelle nicht als normale Entities.

Aber dagegen spricht natürlich auch nichts. Da kannst Du sogar noch ein Feld Validation hinzu nehmen, der dann aber Validierungsregeln für den jeweiligen Typ beinhaltet.

Dann kannst Du darauf zu greifen wie sonst auch bei anderen Entities. Ist natürlich auch voll in Ordnung.

Ich selbst mag halt gerne eine Komponente, die ich injecten kann, die dann entsprechende Getter hat (Das ist der Hauptnutzen bei uns). Der Key interessiert mich im Code nicht, auch wenn er als public in der Klasse definiert wurde.

Ganz wichtig: Das ist einfach nur, was ich gemacht habe. Das wird der Eine oder Andere bestimmt komplett anders sehen....