Hallo Community,
ich arbeite gerade an einem Projekt in dem eine Web-Applikation mit verschiedenen Modulen auf einem Server läuft und meine Aufgabe ist es ein Konzept zum Verwalten der Einstellungen zu erstellen.
Deshalb stellt sich für mich folgende Frage:
Ist es sinnvoll die unterschiedlichen Klassen von Daten zu gruppieren oder lieber trennen?
Damit man die Frage beantworten kann, möchte ich die (relevanten) Klassen von Daten erläutern:
[ul]
[li]Applikations-/Zweckdaten - zur Bearbeitung/Auswertung durch das Programm in einer Datenbank (Artikel, Kunden)
[/li][li]Installations-/Initialisierungsdaten - zum Start des Programms bzw zur Funktionalität des Programms in einer Ini-File (Bsp: Seriennummer, Port des Servers, Name der Datenbank…)
[/li][li]Konfigurationsdaten - Einstellungen, üblicherweise durch ein GUI präsentiert
[/li][/ul]
Um die Konfigurationsdaten geht es nun konkret, sollte man diese lieber zusammen mit den Applikationsdaten in die Datenbank packen oder seperat behandeln (Java Preferences)
Bitte einfach annehmen dass beides möglich ist und sicher funktioniert(wer es genauer wissen will, warums mit Java Preferences geht siehe hier).
Ich wäre eher dafür die einzelnen Klassen der Daten zu trennen. Meine Pros und Cons:
Datenbank:
- schwerer zu implementieren
Datei:
- klare Teilung der einzelnen Klassen
- einfache Implementierung (Methoden zum Import-/Export, Löschen usw. schon gegeben)
- hierarchische Struktur (passend für das Projekt)
- bessere Performanz (bei erstem Zugriff wird alles in eine HashMap geladen)
Was würdet ihr machen?
MfG Moep
Implementierst Du gerade eine Art Configuration Management System nach? Klingt jedenfalls so, wenn man auch Deine Frage von gestern im Hinterkopf hat.
Und zu Deiner Frage: Ganz klar pro Trennung! Ob jetzt Preferences oder DB mag Geschmackssache sein. Ich persönlich würde eher zur DB tendieren, weil lokale Files im JEE-Umfeld ja nicht so gerne gesehen sind. Dann aber auf jeden Fall in einem extra Schema. Nutzdaten und Konfigdaten in der selben DB/dem selben Schema mischen halte ich für nicht so gut.
Ich habe bereits eine Implementierung, welche mit Java Preferences arbeitet. Ich bin eigentlich nur auf der Suche nach Argumenten, die dafür sprechen. Datenbank habe ich nicht gemacht, da mein Betreuer gesagt hat “Datenbank ist zu unperformant”, wobei das meiner Meinung nach nicht stimmt und ich das wohl schlecht in die Arbeit schreiben kann.
Wieso sind lokale Files nicht so gern gesehn?
Wieso sind lokale Files nicht so gern gesehn?
Weil es die Anwendung an den einen Server-Knoten bindet. Das widerspricht dem JEE-Konzept, weil es z.B. Clusterung verhindert (wie werden lokale Files zwischen Knoten synchronisiert?). Bei JEE will man alle Resourcen schön transparent über URLs und JNDI. Ist aber eine sehr strikte Sichtweise, die man in begründeten Fällen nicht teilen muss. Ich wollte da nur mal drauf hinweisen.
Ich bin eigentlich nur auf der Suche nach Argumenten, die dafür sprechen.
Das beste Argument für Preferences im Vergleich zu DB ist in meinen Augen, dass es sich bei der Preferences-API um eine breit eingeführte Standardlösung handelt. Sie ist gut dokumentiert und getestet. Eine DB-Lösung wäre eine proprietäre Eigenentwicklung, welche entsprechend getestet werden muss und in die sich neue Entwickler erst einarbeiten müssen (gut, dürfte nicht so schwer sein). Weit verbreitete Standardlösungen sind (vorausgesetzt sie erfüllen die Anforderungen) immer einer Eigenentwicklung vorzuziehen.
Bei uns im Projekt wird JNDI nirgends verwendet, also hab ich das gar nicht in Erwägung gezogen und ehrlich gesagt bin ich aus JNDI auf die Schnelle nicht schlau geworden.
Vielen Dank für die Infos.
Habe gerade etwas über JNDI gelesen und ich frage mich ob Folgendes möglich wäre:
Eine Properties File die auf dem Server liegt auslesen und mit JNDI binden und dann sind die Strings über mehrere Module(auch JVMs) hinweg erreichbar?
Wenn die Module in einer JVM laufen und Clusterung nicht nötig ist, dann ist aber Preferences wesentlich einfacher und dadurch zu bevorzugen?
Ich finde es sehr verwirrend, wie viele Möglichkeiten es alleine gibt nur um Konfigurationen zu speichern, obwohl das ja vergleichsweise speziell ist.
MfG Moep
Wenn die Module in einer JVM laufen und Clusterung nicht nötig ist, dann ist aber Preferences wesentlich einfacher und dadurch zu bevorzugen?
Ich würde sagen, hier sticht KISS (keep it stupidly simple) eindeutig gegenüber den schlauen Architekturdokumenten einer aufgeblasenen JEE-Spez. Ich wollte nur darauf hinweisen, dass der Einwand kommen kann, mehr nicht.
JNDI war für mich am Anfang auch recht verwirrend. Es ist ganz nett, wenn man den Zugriff auf Resourcen an den Container delegieren will und nicht mehr alles selbst in seiner Anwendung machen muss. Bei JDBC-Datasources oder Mail-Sessions z.B. Es lohnt sich, sich damit zu beschäftigen, wenn man Zeit hat. Ist aber auch kein Beinbruch, wenn man es erstmal nicht verwendet.
Ok Vielen Dank für deine Infos (KISS ist mir auch neu :D).
Finde es super dass man hier so schnell Hilfe bekommt, da ich verdammt im Zeitzwang bin bei meiner Arbeit^^