2
CSharp wpf - klug eine Oracle Connection über mehrere Klassen teilen
Hi,
ich habe eine OracleConnection welche ich in meiner Hauptklasse (MainWindow) in einer wpf (VisualStudio 2017) öffne und Datenabrufe...
einige Informationen möchte ich dann aber "später" noch in einer weiteren Klasse nachladen.
Die offenen fragen sind 1. ist es denn klug die Verbindung zu "vererben"? ... andererseits, finde ich es "unschön" zig mal zu öffnen und zu schließen, wenn ich mir doch sicher bin, dass ich die Verbindung noch brauche (da das Tool ja grundsätzlich davon lebt, mit der Datenbank zu Kommunizieren).
2. Die Verbindungsdaten werden aus einer Config (oder Regedit [da bin ich mir noch nicht zu 100% sicher]) eingelesen. das ganze mach ich im Hauptprogramm direkt nach der Initialisierung (bzw. das gehört selbstverständlich noch zur Initialisierung). Auch hier ist ein "mehrfaches" einlesen eigentlich nur Schade...
Leider bin ich mit dem Klassenübergreifenden auf dem "Holzweg" oder habe einfach nur ein groooooßes Brett vor dem Kof...
sorry, ja ich weiß das sind Basics, dennoch hab ichs geschafft den Schlauch (auf dem ich stehe) komplett abzudichten...
Vielen Dank für jede Information
ich habe eine OracleConnection welche ich in meiner Hauptklasse (MainWindow) in einer wpf (VisualStudio 2017) öffne und Datenabrufe...
einige Informationen möchte ich dann aber "später" noch in einer weiteren Klasse nachladen.
Die offenen fragen sind 1. ist es denn klug die Verbindung zu "vererben"? ... andererseits, finde ich es "unschön" zig mal zu öffnen und zu schließen, wenn ich mir doch sicher bin, dass ich die Verbindung noch brauche (da das Tool ja grundsätzlich davon lebt, mit der Datenbank zu Kommunizieren).
2. Die Verbindungsdaten werden aus einer Config (oder Regedit [da bin ich mir noch nicht zu 100% sicher]) eingelesen. das ganze mach ich im Hauptprogramm direkt nach der Initialisierung (bzw. das gehört selbstverständlich noch zur Initialisierung). Auch hier ist ein "mehrfaches" einlesen eigentlich nur Schade...
Leider bin ich mit dem Klassenübergreifenden auf dem "Holzweg" oder habe einfach nur ein groooooßes Brett vor dem Kof...
namespace blabla
{
public class ConfigData
{
//hier mit getter und setter die Daten public speichern und abrufbar machen
}
public partial class MainWindow : Window
{
ConfigData myCfg = new ConfigData();
public MainWindow()
{
InitializeComponent();
myCfg.data = "irgendwelche Informationen";
myCfg.oraDB = <oracle verbindung>;
}
}
public class ConfigData
{
//und genau hier ist das Problem...
//ohne >new ConfigData< komm ich gerade nicht auf die Variablen
//mit >new ConfigData< erhalte ich die leere Klasse, aber keine Daten, welche ich in MainWindow beschrieben wurden....
}
}sorry, ja ich weiß das sind Basics, dennoch hab ichs geschafft den Schlauch (auf dem ich stehe) komplett abzudichten...
Vielen Dank für jede Information
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 359644
Url: https://administrator.de/forum/csharp-wpf-klug-eine-oracle-connection-ueber-mehrere-klassen-teilen-359644.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
2 Kommentare
Neuester Kommentar
Hi,
du könntest deine Klasse ConfigData als Singleton bauen, dadurch verwendest du dann immer ein und dieselbe Instanz. Allerdings verwendest du dann nicht jedesmal "new ConfigData" sondern eine statische Methode.
Ich behaupte allerdings, dass der Vorgang "Verbindung öffnen - benutzen - danach schließen" eher richtiger wär.
Auch solltest du den Code der die Verbindung öffnet in ein using-Block einbetten.
Mfg E
du könntest deine Klasse ConfigData als Singleton bauen, dadurch verwendest du dann immer ein und dieselbe Instanz. Allerdings verwendest du dann nicht jedesmal "new ConfigData" sondern eine statische Methode.
Ich behaupte allerdings, dass der Vorgang "Verbindung öffnen - benutzen - danach schließen" eher richtiger wär.
Auch solltest du den Code der die Verbindung öffnet in ein using-Block einbetten.
Mfg E
Hallo,
ich würde es ebenfalls als Singleton erstellen.
(Aber vor Nutzung immer testen ob Status=Open und notfalls wieder öffnen) .
Leider ist meist der Aufbau der Connection das Zeitaufwendige, nicht die SQL-Statements die gesendet werden.
(Ist zwar nicht Lehrbuch aber praktikabler)
Gruß
Frank
ich würde es ebenfalls als Singleton erstellen.
(Aber vor Nutzung immer testen ob Status=Open und notfalls wieder öffnen) .
Leider ist meist der Aufbau der Connection das Zeitaufwendige, nicht die SQL-Statements die gesendet werden.
(Ist zwar nicht Lehrbuch aber praktikabler)
Gruß
Frank
