Globale Variable, Singleton oder was ... ?

[SQL-Rookie]

Hallo!

Meine Frage bezieht sich auf das alte Thema globale Variable.

In einer Anwendung bspw. werden bei der Anmeldung bestimmte Paramater mitgegeben (z.B. Welche Datenbank genutzt werden soll?, Welcher User?).Aus diesen Anmeldeinformationen wird ein connectionstring gebildet, den ich immer und immer wieder in der Anwendung benötige.

Nun hab ich gelernt/gelesen:

Globale Variablen (also, die permanent im Speicher gehalten werden) sind böse in der OOP (ich weiß, ist flapsig ausgedrückt)

Dann hab ich das Singleton Pattern gefunden dann lese ich: Auch nicht wirklich gut. Auch böse.


Mir geht es jetzt nicht um die Bewertung der beiden Punkte, sondern um die Frage, wie Ihr mit meiner oben genannten Anforderung umgehen würdet, wenn keine globalen Variablen und kein Singleton Pattern. Gibt es weitere Alternativen? Oder soll ich die Werte am besten in eine xml Datei speichern und jedesmal wieder neu laden, wenn ich sie brauche?



Danke.

Marco

[Ralf Jansen]

Singleton ist nicht böse. Es gibt leider nur soviele Möglichkeiten wie man einen Singleton implementieren könnte und eher akademische Auseinandersetzungen welche denn am besten ist.

Deinen Connectionstring kannst du doch einfach in der App.config ablegen. Wenn du in den Projektoptionen unter Settings einfach mal einpflegst (es gibt da sogar einen ~pseudo~ Connectionstring typen) genriert dir VS eine Settings Klasse um auf die Einstelllungen zuzugreifen. Und wär hätte das gedacht die Settings klasse ist eine Singleton Implementierung die ihre Einstellung an einer statischen Property (die Default heißt) veröffentlicht. Wen du lieber was eigenes machst dann schau dir halt die Implementierung der Settingsklasse an und ersetze den Teil zum lesen aus der App.Config durch was anderes zum Beispiel ein simples Dictionary das deine Einstellungen hält.

[Wernfried]

In fast allen meinen Applikationen habe ich ein globales Package/Modul/Klasse/etc., in dem ich diverse Konstanten definiere, welche innerhalb der Applikation immer wieder und an den verschiedensten Stellen verwendet werden und die sich nur schlecht fix einer bestimmten Klasse o.ä. zuordnen lassen. In Ausnahmefällen können dort auch mal ein oder zwei Variablen definiert sein.

Ich finde man sollte da die Kirche im Dorf lassen und es nicht zu akademisch sehen. Der Aufwand um es streng nach Lehrbuch zu machen steht einfach in keinem Verhältnis zum Nutzen.

Gruss

[Ralf Jansen]

Da hast du Recht wenn man einfach direkt von irgendwo auf diese Klasse mit den ~globalen~ Variablen zugreift also zum Beispiel bei den Settings direkt auf Settings.Default.MeineProperty dann kann ich genauso gut auch einfach eine statische Klasse nehmen dann hat man vom Singleton Ansatz keinerlei Gewinn. Denn wenn sich irgendwann mal die Anwendung so ändert das man mehrer Sätze dieser Einstellungen braucht (zum Beispiel weil der Prozess Mandantenfähig wird und je Mandant ein Thread mit seinen eigenen Einstellungen braucht muss man eh alle Stellen anpacken und ändern da jetzt eine Instanz nötig ist und keine statische Klasse mehr.

Sinn macht Singleton eigentlich erst wenn man einen serviceorientierten Ansatz wählt. Also im einfachsten Fall alle potentiellen Nutzerklassen die Settings an eine eigene Property zugeordnet bekommen und selbst nur über ihre eigene Property nutzen. Dann muss man später nur den Service ändern der die Settings zuordnet. Alle Nutzerklassen bleiben unverändert und funktionieren so weiter. Das einzige was man neu testen müsste wäre der Service der die Settings zuordnet.

[SQL-Rookie]

Ich finde man sollte da die Kirche im Dorf lassen und es nicht zu akademisch sehen. Der Aufwand um es streng nach Lehrbuch zu machen steht einfach in keinem Verhältnis zum Nutzen.

Gruss

Vielen Dank erstmal für Eure Beiträge

So wie Wernfried es würde ich es mit dem Satz beschreibt, ist es auch meine Erfahrung. Gerade, wenn man, wie ich, das Ganze nur hobbymäßig betreibt, muss man Kompromisse eingehen.

ich denke, ich bleibe bei den globalen Variablen, auch wenn es böse ist

[fanderlf]

Globale Variablen sind nicht per se böse und absolut zu vermeiden. Vor allem dann nicht wenn sie später im Programm nur gelesen und nicht mehr verändert werden können. Wenn sowieso nur Du an Deinem Quellcode arbeitest kannst Du Dir auch komplizierte Konstrukte sparen. Du solltest statische Variablen nach Möglichkeit nur einmal setzen (in deinem Beispiel beim Start des Programms) und danach nur noch lesen. Wenn Du nur liest ist alles Threadsafe und Du bist auf der sicheren Seite. Tiefere Gedanken muss man sich nur machen wenn man das Objekt während der Laufzeit verändern/schreiben will (Stichwort hier z.B. Caches). Aber auch dafür gibt es mittlerweile sehr gute fertige Konstrukte im .Net Framework (z.B. ConcurrentDictionary).

[SQL-Rookie]

Globale Variablen sind nicht per se böse und absolut zu vermeiden. Vor allem dann nicht wenn sie später im Programm nur gelesen und nicht mehr verändert werden können. Wenn sowieso nur Du an Deinem Quellcode arbeitest kannst Du Dir auch komplizierte Konstrukte sparen. Du solltest statische Variablen nach Möglichkeit nur einmal setzen (in deinem Beispiel beim Start des Programms) und danach nur noch lesen. Wenn Du nur liest ist alles Threadsafe und Du bist auf der sicheren Seite. Tiefere Gedanken muss man sich nur machen wenn man das Objekt während der Laufzeit verändern/schreiben will (Stichwort hier z.B. Caches). Aber auch dafür gibt es mittlerweile sehr gute fertige Konstrukte im .Net Framework (z.B. ConcurrentDictionary).

Danke nochmal dafür. Genau das mache ich: Ich setze beim Start des Programms (vielmehr bei der User-Anmeldung) einmal den Connectionstring auf Basis der Eingaben. Das verändert sich nicht. Ob alles threadsicher ist, naja, dafür will ich meine Hand nicht ins Feuer legen. Aber wie gesagt, ich mach das ja auch nur hobbymäßig ...

Insofern danke nochmal für die Bestätigung.