Wo und wie Daten die für alle Benutzer bestimmt sind verwalten

[Fant]

Hallo zusammen!

Folgendes minimalisiertes Szenario:
Ich habe in meiner Webapplikation etwa ein DropDown-Menü. Die Liste der Auswahlmöglichkeiten würde ich gerne so gestalten, dass sie im laufenden Betrieb verändert werden kann. Für alle Benutzer sollen aber die selben Auswahlmöglichkeiten existieren.

Ich kann sie also natürlich nicht hartcodiert im Quellcode hinterlegen. Auch würde ich gerne darauf verzichten die Daten in irgendwelchen extra Textfiles zu speichern..

Was ist nun der saubere Weg, um diese Auswahlliste dem Benutzer zur Verfügung zu stellen? Pack ich die Liste in eine BackingBean im ApplicationScope? Oder hole ich mir die Auswahloptionen für jede View-Anfrage neu aus einer Datenbank? Oder macht man besser etwas ganz anderes?

Gruß und Danke
Fant

 

[nillehammer]

Pack ich die Liste in eine BackingBean im ApplicationScope?

Kann man machen, allerdings würde dann das Hinzufügen/Wegnehmen von Auswahlmöglichkeiten bedeuten, dass Du die Applikation durchstarten musst. Kommt also nur in Frage, wenn sich die Auswahlmöglichkeiten nur sehr selten ändern. Die Auswahl eines Bezahlweges (Kreditkarte, Überweisung, Lastschrift) wäre bspw. ein fachliches Szenario, für das dieser Weg passen könnte.

Oder hole ich mir die Auswahloptionen für jede View-Anfrage neu aus einer Datenbank?

Das wäre der Weg, den ich erstmal immer gehen würde. Damit umgehst Du in jedem Fall den nötigen Neustart der Applikation. Evtl. um den Preis, dass Du bei sich selten ändernden Auswahlmöglichkeiten immer die selben Results von der Datenbank bekommst und deswegen eigentlich unnötige Abfragen an die DB sendest. Bei relativ kleinen Auswahllisten sollte das Performancemäßig nicht so ins Gewicht fallen. Nur, wenn Du wirklich sicher bist, dass hier ein Bottleneck entsteht, falle auf die erste Variante zurück.

 

[Fant]

Die Datenmenge fällt nicht wirklich ins Gewicht. In meinem Fall sind es etwa 10 verschiedene Zusammenstellungen aus etwa 20 Einträgen. Der Zugriff auf die Datenbank erfolgt ohnehin über einen EntityManager, der ja auch noch die Daten cached, so dass die tatsächlichen Datenbankzugriffe ja eigentlich in einem recht überschaubaren Rahmen bleiben sollten?

Wieso aber macht eine Änderung einer Bean im ApplicationScope einen Neustart der Application erforderlich? Das ist mir nicht wirklich klar..

 

[nillehammer]

Wieso aber macht eine Änderung einer Bean im ApplicationScope einen Neustart der Application erforderlich? Das ist mir nicht wirklich klar..

Hatte Deine Frage so verstanden, dass Du die Listen einmal initialisieren und in den ApplicationScope packen wolltest. Und da wäre der Initialisierungszeitpunkt eben der Start der Anwendung gewesen. Alles andere wäre in diesem Zusammenhang auch unüblich bis fehlerhaft gewesen.

 

[Fant]

Du hast schon recht damit, dass ich die Listen beim Start der Anwendung initialisieren und dann in den ApplicationScope packen würde. Anschließend aber würde ich diese Liste über normaler getter/setter pflegen, da ich die App eben nicht neu starten möchte.
Aktualisiert ein Benutzer dann seine View, dann bekommt er sofort die neuen Listen angezeigt. Jedenfalls dachte ich mir das so 😉 Früher passiert das bei der anderen Variante ja auch nicht.

Das einzige Problem, was mir einfällt, wäre der Fall, dass ein Benutzer genau zu dem Zeitpunkt über eine der Listen iteriert, während diese an anderer Stelle geändert wird.
Wenn ich aber davon ausgehen darf, dass es aus verschiedensten Gründen nicht zu solch einem Fall kommen kann, gäbe es dann trotzdem noch Gründe, die gegen dieses Vorgehen sprechen würden?
Oder aus welchen Gründen stufst du das als fehlerhaft ein?