Pseudo-globale Variable

[Michael Steidl]

Ich komme aus der Delphi-Ecke und da gab es bequeme applikationsweite globale Variable, z.B. für eine Datenbankverbindung. Bekanntweise geht es in C# nicht so einfach - aber ich habe bisher kein Workaround gefunden und mir nun folgendes ausgedacht:

Problemstellung: Zugriff auf EINE Datenbank aus mehreren Klassen. Werden die Datenbankverbindungen lokal angelegt, endet man bei mehreren aktiven DB Verbindungen - das soll/darf nicht sein.

Zielsetzung: Eine Variable die aus mehreren Klassen ansprechbar ist.

Rezept:
Man nehme:
- Eine Klasse mit einer "public static" Variablen, von einem beliebigen Typ, etwa auch einer Datenbank-Verbindung.

- Im Constructor der Klasse wird die Variable instanziert, bei einer DB Verbindung wird diese damit aufgebaut.

- Allen involvierten Klassen greifen auf diese statische Variable zu.

- Eine (aber eben nur eine einzige) der involvierten Klassen (etwa die Applications Klasse) muss die Instanzierung der oa. "Hüllklasse" vornehmen.

Frage an die Community: gibt's da noch wo einen Pferdefuss, den ich bisher nicht gesehen habe?

Danke für Kommentare
Michael

[Henry Krick]

Kann sein, dass du das gleiche meinst was ich jetzt sage, aber ich hab es immer so gelöst:

1. public static Methode um Verbindung abzurufen
2. Singleton-Implementierung, damit muss kein externer Aufruf des Constructors erfolgen, was die Flexibilität wieder erhöh

[Helmut Markus Seidl]

Grüß Dich Michael,<br><br>
So ganz verstehe ich nicht warum Du eine Klasse, die Du statisch verwenden möchtest instanzierst. Die instanzierte Klasse kann zwar auf seine statischen Elemente zugreifen, macht aber nur in seltenen Fällen auch sinn. Man überlege: Wenn ich jetzt die Klasse zweimal instanziere, dann rufe ich den Konstruktor auch zweimal auf -> Damit baue ich dann auch 2 mal eine Verbindung zu einer Datenbank auf. Was Du möchtest, ist ja EINE globale "storage" für Deine Verbindung. Demnach macht das Verbinden zu einer Datenbank im Konstruktor nur wenig Sinn.<br><br>
Deswegen: Mache es so wie Henry es schon gesagt hat. Erstelle eine eigene Klasse für diese Verbindung (damit kannst Du dann die Verbindung auch gleich viel schöner verwalten), welche im wesentlichen NUR statische Felder, statische Funktionen und statisch Eigenschaften verwendet. Modifziere alles das öffentlich was Du benötigst. Und damit hast Du eine Globale Verwaltung für Deine Datenbankverbindung.<br><br>
Ich denke sowieso, dass man diese globalen Variablen eigentlich nie braucht (und für den seltenen Fall dass man sie vielleicht doch braucht, lege ich halt mal ausnahmsweise wirklich EINE Klasse für EINE statische Variable an), weil grad bei einer Datenbankverbindung gleich noch eine Verwaltung hinzukommt, dafür lohnt es sich doch dann gleich eine eigene Klasse anzulegen.<br><br>

Markus Seid

[Roger Bieri]

Michael, wieso soll/darf es denn nicht sein, dass du mehrere Verbindungen hast ?

ADO.NET ist ja jetzt disconnected und hat (zumindest für den SQL-Server) Connection Pooling..

[Michael Steidl]

Danke für die Kommentare:

zu Henry und Markus:

Danke für den Tipp, die Verbindung über eine statische Methode herzustellen, dieser Verbindungaufbau war nämlich der einzige Grund, die Klasse zu instanzieren. Dh. ich packe nun statische Variable und Methode in eine eigene Klasse, die nur diesem Zweck dient.

zu Roger:
Ich arbeite mit dem Oracle Data Provider for .NET, der unterstützt auch Connection Pooling. Allerdings gibt es da auch Grauzonen: wie ist das mit BeginTransaction und Commits von solchen "gepoolten Connections" - werden die bzw. können die exakt auseinandergehalten werden? Leider gibt es dazu keine Dokumentation und nur selber ausprobieren ist mir zu vage. Da definiere ich lieber gleich vom Anfang an eine einzige Connection und kann da etwa diese Transactions besser verfolgen. (Wahrscheinlich spielt da noch ein konservativ/vorsichtiger Blick aus der Delphi-Ecke mit.)

Viele Grüße

Michae