Laden...

Richtige Einbindung einer Datenschicht-Klasse

Erstellt von Michael Günther vor 15 Jahren Letzter Beitrag vor 15 Jahren 2.030 Views
M
Michael Günther Themenstarter:in
4 Beiträge seit 2008
vor 15 Jahren
Richtige Einbindung einer Datenschicht-Klasse

Hallo, zusammen!

Ich habe im Buch "Windows Forms 2.0 and Custom Controls with VB 2005" (ich weiss ... VB ...) den Hinweis gefunden, dass man eine Datenschichten-Klasse auf drei unterschiedlichen Wegen in seine Applikation einbinden kann:

  1. Instanziierung in jeder einzelnen Windows Form
  2. Von überall aus ansprechbar als Klasse mit statischen Methoden
  3. Instanzierung einer Objektvariablen in Program.cs in Main(), die über eine statische Eigenschaft zur Verfügung gestellt wird

Ich möchte nun gerne wissen, welchen Weg ihr empfehlt und dabei gerne erfahren, welche Vor- und Nachteile die jeweils anderen beiden Möglichkeiten Eure Entscheidung beeinflusst haben. Ich selbst empfinde nur den ersten Weg als lästig, da in jeder einzelnen Windows Form erst mal instanziert werden muss, bin mir aber nicht im klaren, welche Argumente für oder gegen Methode 2 und 3 sprechen.

Freue mich schon auf den Gedankenaustausch!

Viele Grüße,
Michael Günther

365 Beiträge seit 2007
vor 15 Jahren

Hallo Michael Günther,

Ich nutze oft die 2te Art und Weise und zwar eine statische CConnection Klasse
die immer nur 1 mal vorhanden ist. So musst du Sie nur 1 mal instanzieren
und kannst von überall her auf Sie zugreifen.

Vorteil:
Es ist Resourcensparender wenn man nur 1 SqlConnection Objekt instanziert
und immer weiterverwendet, statt für jede einzelne Datenbankmanipulation
ein neues zu erzeugen. Ob das jetzt bei deinem Programm nötig ist, musst du selbst herausfinden.

Du könntest aber sofort mit Linq einsteigen und müsstest dir um Verbindungsobjekte keine Sorgen mehr machen.
Das erledigt Linq selbstständig für dich. 1 mal Verbindungszeichenfolge übergeben
und du musst dich nicht mehr um das instanzieren, öffnen und schliessen kümmern.

Weiterhin gibt es das Entity Framework, das eigene Konkurenzprodukt von unserem Redmonder Software Riesen zu Linq. Linq wird wohl nicht mehr weiterentwickelt,
jedoch bleibt es eine schöne einfache Möglicheit Abfragen gegen die Datenbank zu senden.
Das Entity Framework wird weiterentwickelt. Einen Blick auf jeden Fall wert. 👍

So long da kubi.

84 Beiträge seit 2007
vor 15 Jahren

Hallo Michael Günther,

Weiterhin gibt es das Entity Framework, das eigene Konkurenzprodukt von unserem Redmonder Software Riesen zu Linq. Linq wird wohl nicht mehr weiterentwickelt,
jedoch bleibt es eine schöne einfache Möglicheit Abfragen gegen die Datenbank zu senden.
Das Entity Framework wird weiterentwickelt. Einen Blick auf jeden Fall wert. 😮

So long da kubi.

Hier ist allerdings anzumerken, dass nur LINQ 2 SQL betroffen ist, nicht die LINQ-Abfragetechnologie selbst, denn diese kommt ja auch beim Entity Framework zum Einsatz (und wird dann dort nochmal in Entity SQL übersetzt).

Grundsätzlich stelle LINQ ja nur eine Möglichkeit zur Abfrage von Daten da, und kann für verschiedene Datenquellen gewnutzt werden, solange diese bestimmte Schnittstellen implementieren.

@ Michael Günther:

Eine kombinierte Lösung wäre auch denkbar. Jede Instanz einer DataAccess-Klasse greift dann z.B. auf das gleiche, als statisch deklarierte SQLConnection-Feld zu.
So kommt es zu keinen Scherereien mit mehreren Verbindungen, und du kannst die weiteren Felder und Methoden der Klasse trotzdem individuell nutzen.

T
223 Beiträge seit 2006
vor 15 Jahren

Hallo,

Bei Datenbankverbindungen gehe ich in der Regel den Weg über ein Singleton. Damit kann ich mir ein Objekt der Datenbankverbindung dort holen, wo ich es brauche (bei dir eben in den Forms) und ich kann gleichzeitig sicherstellen, dass es nur ein Objekt dieser Art gibt.

Deine Forms enthalten eine Zeile Code, um dieses Objekt zu bekommen. Database ist die Singleton Klasse, welche die Connection verwaltet. GetInstance ist eine statische Methode.


private SqlConnection mDatabase = Database.GetInstance();

Gruß Thomas

84 Beiträge seit 2007
vor 15 Jahren

Falls dir das Singleton-Pattern nicht geläufig sein sollte, kannst du auch einfach static verwenden. In den allermeisten Fällen ist es eher eine Glaubensfrage, ob static oder singleton zum Einsatz kommt.

(Wobei ich damit nun nicht den Beitrag von Thomas B. herabsetzen will.)

Gruß,
Razer

2.187 Beiträge seit 2005
vor 15 Jahren

Hallo,

Bei Datenbankverbindungen gehe ich in der Regel den Weg über ein Singleton.

Hoffen wir das mal nicht. MS empfihlt auf jeden Fall das Gegenteil! Aber gut, Microsoft wird natürlich die Passende Technologie für seinen Server empfehlen.

In den allermeisten Fällen ist es eher eine Glaubensfrage, ob static oder singleton zum Einsatz kommt.

Definitiv nicht. Das Singelton-Patern hat mehrer Vorteil:

  • Du kannst den Zugriff auf das Objekt steuern.
  • Du kannst das Objekte erst bei bedarf erstellen.
  • Du verwendest Instanz-Member, bei denen man nicht auf Thread-Sicherheit achtet (bei static-Membern kann man das erwarten).
  • Die Member können durch Vererbung beeinflusst werden (erfordert je nach Programmiersprache jedoch einen zusätzlichen Aufwand im Singelton).

Ich möchte nun gerne wissen, welchen Weg ihr empfehlt und dabei gerne erfahren, welche Vor- und Nachteile die jeweils anderen beiden Möglichkeiten Eure Entscheidung beeinflusst haben. Ich selbst empfinde nur den ersten Weg als lästig, da in jeder einzelnen Windows Form erst mal instanziert werden muss, bin mir aber nicht im klaren, welche Argumente für oder gegen Methode 2 und 3 sprechen.

Also ich würde eine Variante von weg 2 empfehlen. Eine eigene Klasse schreiben, die man Instanziiere, wann immer man Sie braucht. So kann man das Verhalten innerhalb der eigenen Klasse im Notfall anpassen.
zu 1: Das ist denkbar schlecht, da man dann den Code in jeder Form immer wieder Tippen muss!
zu 3: Das ist auch nur eine schlechtere Variante von 2. Dann lieber eine saubere, wiederverwendbare Klasse.

Jetzt aber mal im allgemeinen: Die Forms haben nichts auf der Datenschicht/Datenbank zu suchen. Da "muss" noch eine Schicht dazwischen. Forms sollten nur die Business-Logik, diese auch nur über interfaces ansprechen und im allgemeinen so wenig Code wie möglch enhalten (nur das, was direkt mit der Anzeige zu tun hat). Dieses 3-Schichten-Model (oder n) ist schon sehr alt und hat seine Berechtigung, das kann man in jeder vertrauenswürdigen Quelle (z.B. http://de.wikipedia.org/wiki/Schichtenarchitektur @herbivore: bitte nicht <Title> der Website einfügen! ) nachlesen.

Gruß
Juy Juka

[EDIT]PS: Herzlich wilkommen im Form Michael Günther[/EDIT]