Wo eingeloggten Benutzer "speichern"

[UnkiDunki]

Hi,

ich habe eine kurze Frage:

Wo "speichere" ich am elegantesten einen erfolgreich eingeloggten Benutzer? Mein Login-Dialog gibt mir bei erfolgreicher Anmeldung den entsprechenden Benutzer zurück auf den bzw. seine Rechte ich von nun an überall in der GUI Zugriff haben müsste.

Ich möchte aber auch nicht überall den User als Parameter mit durchschleusen, sondern das sollte schon eleganter geschehen.
Wie bzw. wo wird das am besten gemacht? Als z.B. statische Variable im Frame?

Danke im Voraus

 

[SlaterB]

stell dir erstmal vor du bleibst beim Durchschleusen, welche Klassen sind denn betroffen,
wie ist bisher das Programm strukturiert, wer macht was?
hast du eine Klasse pro größeren GUI-Abschnitt mit dem GUI-Code (Auflistung aller JButtons, Layout usw), oder separate Controller-Klassen?
hast du schon irgendwas anderes zentral organisiert, benötigen vielleicht mehrere Stellen Zugriff auf das JFrame-Objekt, wird das als Parameter durchgereicht?

statische Variablen sind unschön, nach Möglichkeit besser wirklich Parameter verwenden,
die Arbeit damit aber reduzieren, möglichst nur ein Objekt, einer eigenen Klasse ControlData oder so, wo User und andere Infos eingetragen sind,
das wird standardmäßig im Konstruktor überall übergeben, wenn in einem Programmteil der Login stattfindet, muss nicht unbedingt jeder andere neu mit Methodenaufruf/ Parameter versorgt werden, über das gemeinsame Objekt ist der User überall bekannt

 

[UnkiDunki]

Hi SlaterB,

danke schon mal für dein Interesse

Also...

stell dir erstmal vor du bleibst beim Durchschleusen, welche Klassen sind denn betroffen,
wie ist bisher das Programm strukturiert, wer macht was?
hast du eine Klasse pro größeren GUI-Abschnitt mit dem GUI-Code (Auflistung aller JButtons, Layout usw), oder separate Controller-Klassen?
hast du schon irgendwas anderes zentral organisiert, benötigen vielleicht mehrere Stellen Zugriff auf das JFrame-Objekt, wird das als Parameter durchgereicht?

Durchschleusen würde sehr viele Klasse betreffen, daher ist das kein gute Wahl.
Ich versuche alles nach dem MVC-Konzept zu realisieren, also seperate Controller-Klassen. Am ehesten würde ich sagen, dass man das JFrame Objekt durchschleusen könnte bzw. dessen Controller vielleicht? Es muss ja sowieso darauf geachtet werden, dass etwaige Änderungen in anderen Bereichen beim Schließen des Frames auch noch eine Sicherheitsabfrage nachsichziehen, daher muss es ja generell mit allen anderen Bereichen in Verbindung stehen.

statische Variablen sind unschön

Ja genau, deshalb habe ich hier mal nachfragen wollen, wie das am besten umzusetzen wäre. Ne Klasse ControlData ist natürlich eine Klasse(n) Idee, da beschränkt man alles auf einen Parameter. Das ist schon mal nicht schlecht!

Generell ist es so, dass ich im MainFrame bzw. in dessen Controller alle Panels, Dialoge etc. anlege. Von dort könnte man dann entsprechend eine ControlData-Klasse oder das Main selber übergeben...

 

[SlaterB]

wenn du eine eigene Klasse extends JFrame hast und die überall bekannt ist, dann könnte User dort eine (nicht-statische) Variable sein,
dann übernimmt JFrame-Klasse die ControlData-Funktion, ob man das später noch auftrennt wäre keine dramatische Entscheidung,

wobei genaugenommen auch eine statische Variable mit ähnlichen Aufwand später auszubauen ist,
so wichtig sind solche Entscheidungen in kleinen Programmen nicht,
mache es so wie es geeignet scheint und bei guten Gründen umstellen

drei Dinge, die man hier als ziemlich richtig gleich bedenken könnte, wie eigentlich fast immer und überall:
- besser nicht statisch
- ein Parameter mit vielen Infos ist besser als zwei einzelne, wenn man sie in einem größen Objekt zusammenlegen kann
- allgemeine Programmdaten wie User/ Rechte eher nicht in einer Swing-beschränkten Klasse wie JFrame ablegen (was vielleicht gar kein Thema ist, habe ich nur selber engebracht)

 

[_Andi91]

Ich würde das ganze mit einer Singleton Klasse realisieren. D.h. von dieser Klasse kann es nur eine Instanz in der Anwendung geben. In der speicherst du dir dann diese zentralen Parameter.

(hier noch ne nützliche Seite zu Singletons, bzw. allgemein Design Patterns: Singleton Design Pattern)

 

[UnkiDunki]

@SlaterB: Danke für die Ausführungen. Bei einem eingeloggten Benutzer bleibt es ja nicht, dann habe ich z.B. noch eine Klasse mit Formaten, wie Datumsformaten, etc. - Da müsste man sich vielleicht wirklich überlegen das Ganze irgendwie zusammenzufassen und mit einer ControlData-Klasse zu realisieren.

@_Andi91: Singletons hören sich interessant an. Danke für den Einwurf Wobei ich gerade lese, dass da viele Leute hier im Forum nicht so begeistert von sind...

 

[SlaterB]

im wesentlichen ist ein Singleton eine statische Variable, also ohne 10 Seiten Diskussion ganz normal leicht unschön, wie das mit statischen Variablen so ist,
der Rest ist eigentlich unwichtig

 

[Murray]

Ich würde das ganze mit einer Singleton Klasse realisieren.

Ich nicht unbedingt.

Ohne jetzt den üblichen "Singletons-Sind-Ganz-Ganz-Böse"-Kanon anstimmen zu wollen: Singletons werden doch dort eingesetzt, wo es in der Natur der Sache liegt, dass bestimmte Daten innerhalb eines (Software-)Systems garantiert nur einmal auftauchen können. Da Multi-User-Umgebungen heute ja durchaus nichts ungewöhnliches sind, würde ich dem Benutzer einer Anwendung diese Eigenschaft nicht unbedingt zusprechen.

Allerdings hat Slater natürlich (wie so oft) Recht, wenn er sagt, dass bei kleineren Projekten der Aufwand, der notfalls auf einen zukommt, wenn man irgendwann mal bemerkt, dass man mit statics nicht mehr auskommt (weil man z.B. aus einer Single-User- eine Multi-User-Anwendung macht) normalerweise durchaus überschaubar bleibt; insofern muss man das nicht unbedingt dogmatisch sehen - in einer (Single-User-)Desktop-Anwendung könnte man nach Abwägen der Pros und Cons vielleicht wirklich zu dem Schluss kommen, dass ein Singleton passt - das müsste aber wirklich das Resultat sorgfältigen Nachdenkens sein; als Standard-Pattern für diese Art von Problem taugt das Singleton m.E. nicht.

 

[UnkiDunki]

Mhmm ok,

klar, am besten nichts statisches und Singletons gehören ja praktisch dazu. Das würde ja SlaterB's Rat ja mehr oder weniger widersprechen, wenn ich sie jetzt benutzen sollte.

Fast ich habe mit Sicherheit sagen kann, dass es eine (Single-User-)Desktop-Anwendung ist und bleiben wird, was aber nicht heisst, dass man dann nicht schon für Multi-User programmieren sollte, weil das vielleicht im nächsten Projekt anders ist und dann hätte man schon etwas, auf das man zurückgreifen könnte... von daher...

am Ende werde ich wohl doch zum "Schleuser"

 

[_Andi91]

Naja in einer GUI Anwendung ist in der Regel ja immer nur ein User angemeldet.
Ansonsten kann man von Singletons halten was man will. Ich kann nur sagen, dass ich einige Produktivsysteme kenne wo Singletons genau für dieses Problem verwendet werden.

 

[Tomate_Salat]

dass bestimmte Daten innerhalb eines (Software-)Systems garantiert nur einmal auftauchen können.

Ist das hier nicht der genau der Fall?! Ich wüsste jetzt nicht, warum man sich auf einer Desktop-Anwendung mit n>1 Benutzer anmelden sollte :-/.