Laden...

Bei mehreren Forms ConnectionString und Userdaten als Singleton?

Erstellt von D.I. vor 16 Jahren Letzter Beitrag vor 16 Jahren 1.614 Views
D
D.I. Themenstarter:in
20 Beiträge seit 2007
vor 16 Jahren
Bei mehreren Forms ConnectionString und Userdaten als Singleton?

Hallo Community,

hier geht es nicht direkt um ein Problem, sondern um die Frage nach einem eleganten Design. Zur Zeit entwickle ich eine Anwendung mit UserAuthentifizierung, mehreren Forms (je nach Berechtigung) und Datenbank Zugriff.

Bisher bin ich so verfahren, dass ich die Datenbank-Connection (MySQL) und den User (eigene Klasse mit User-Informationen) in einem unsichtbaren ControlForm angelegt und dann an die einzelnen Forms übergeben habe. Die Forms kennen sich also nicht untereinander sondern werden von einer zentralen Stelle (ControlForm) erstellt und bekommen als Parameter den User und die DBConnection. Das mit dem zentralen Form hab ich hier aus dem Forum 🙂

Nun habe ich im Forum gelesen, dass es schlechtes Design ist eine einzelne DBConnection zu verwenden (egal ob als Singleton oder per Übergabe). Es wäre nun aber umständlich jedesmal den ConnectionString aus den Settings zusammenzubasteln. Es liegt also auf der Hand für den ConnectionString und den User das Singleton-Pattern zu verwenden.

Liege ich mit meinem Ansatz richtig? Wie verfahrt ihr bei solchen Problemen und wo setzt ihr in euren Projekten das Singleton-Pattern ein? Gibts zu dem Thema vllt. sowas wie eine Best Practise die ich übersehen habe? Und wie händelt ihr das Mit der Authetifizierung und den verschiedenen Forms? Ich habe dazu 2 Ansätze:

  1. AnmeldeForm -> ClientForm

  2. ControlForm(unsichtbar) -> AnmeldeForm
    ControlForm(unsichtbar) -> ClientForm

Gruß David

100 Beiträge seit 2006
vor 16 Jahren

Wenn du eine wirklich große Applikation hast und das Problem der verschiedenen Dienste wirklich gut lösen möchtest, würde ich das Lesen von

Dissecting a CSharp Application empfehlen.
In Kapitel 3 geht es um eine Property-Architektur.

In Verbindung mit Kapitel 5 kannst du einmal einen Service für zentrale Programmeinstellungen oder auch einen Service für immer wiederkehrende Dateioperationen erstellen.

Irgendwo im Programm hast du dann beispielsweise folgenden Code:


PropertyService prop = (PropertyService) ServiceManager.Services.GetService(typeof(PropertyService));

String con = prop.GetProperty("ApplicationConnectionString");

3.825 Beiträge seit 2006
vor 16 Jahren

Hallo David,

ich habe eine eigene Klasse für alle Datenbank-Operationen, die den Connectionstring erstellt. Wie der dann erzeugt wird ist egal, hängt ja auch vom Datenbanktyp ab.

Den Connectionstring brauche ich aber eigentlich nie in der Applikation, weil alle Datenbankzugriffe auch in dieser Klasse gekapselt sind.

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

D
D.I. Themenstarter:in
20 Beiträge seit 2007
vor 16 Jahren

Das mit den Services sieht nicht schlecht aus, aber für meinen Fall etwas zu groß/kompliziert. Ich werde es aber mal im Hinterkopf behalten 😉

Was die Datenbank-Klasse und das "gekapselt" angeht, wie muss ich mir das vorstellen? Angenommen man hat eine Datenbank mit Kunden, Produkten und Bestellungen und möchte dies auf Klassen abbilden. Ist es dann nicht sinnvoll jeweils eine Klasse mit den Methoden load und save zu schreiben? Aus Sicht der OOP sollen die Klassen Kunden, Produkte und Bestellungen ihre Methoden zum Speichern/Laden ja quasi mitbringen.

So wie Bernd es beschreibt verstehe ich es so, dass es eine Klasse (z.B. DBManager oder sowas) gibt, die die Methoden Save/LoadKunden, Save/LoadProdukte und Save/LoadBestellungen hat und die Daten jeweils zurückliefert... Man hätte dann natürlich eine zentrale Stelle für alle Datenbank-Zugriffe was auch wiederrum praktisch ist. Aber was ist denn nun aus Sicht der OOP richtig und/oder elegant?

3.825 Beiträge seit 2006
vor 16 Jahren

Hallo D.I.,

die die Methoden Save/LoadKunden, Save/LoadProdukte und Save/LoadBestellungen

Nein, meine Methode heisst nur Load / Save. Die Datenbankschicht ist Tabellen-unabhängig und kennt die Datenbankstruktur nicht. Die geladenen Tabellen sind dann in einem Dataset.

Es gibt für jede Tabelle eine eigene Klasse mit Objekten, z.B. eine Klasse Adressen, eine Belege etc.

ist denn nun aus Sicht der OOP richtig und/oder elegant?

Weiss ich nicht, aber es ist schnell, fehlerunanfällig und praktisch 😉

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

D
D.I. Themenstarter:in
20 Beiträge seit 2007
vor 16 Jahren

Original von BerndFfm
Es gibt für jede Tabelle eine eigene Klasse mit Objekten, z.B. eine Klasse Adressen, eine Belege etc.

Wenn ich das richtig verstanden habe lädst du die Tabellen erstmal in ein Dataset und füllst dann deine Klassen damit. Enthalten die Objekte dann nur Verweise auf das Dataset?

Mich würde ein Beispiel dazu interessieren. Besonders wie du einzelne Tabellen lädst und dann eine Klasse damit füllst (z.B. Kunden).
Gibst du deine Load-Funktion den Tabellenname mit und sie liefert dir dann den entsprechenden DataTable aus dem Dataset den du dann durchläufst und Objekte vom Typ Kunde erzeugst? Ich stell mir das Ganze ziemlich praktisch vor, aber leider hab ich im Umgang mit Datasets wenig Erfahrung.

Gruß David