[Design] Datenbank + Programm
 

Hi Analytiker und Programmierer!

Ich brauche eine Kunden/Artikel/Rechnungsverwaltung. Schön ;)
Das ganze soll rein OO gelöst werden; im Hintergrund spielt eine Access-Datenbank den Speicher (kann ich ja später mal leicht "aufrüsten") und "vorne" programmier ich mit .NET.

Jetzt habe ich folgendes Problem:
Wie greife ich auf die DB zu?

Wie es rein technisch, von .NET aus funkt, ist mir schon klar. Aber ich hab ein DB-Konzept und ich hab Formulare und Klassen in der Anwendung. Aber ist die Datenbank quasi ein "globales Objekt" auf das alle anderen Klassen zugreifen können, gebe ich dieses DB-Objekt an alle anderen Klassen mit oder leite ich alle Klassen von diesem DB-Objekt ab?

Hat da schon jemand Erfahrung, wie man so eine Anwendung designt?

Re: [Design] Datenbank + Programm
 

Auf ein globales Objekt kannst du von jeder Klasse aus zugreifen. Also brauchst du es nicht an die Klassen mit zuübergeben.
Jede Klasse von der DB-Klasse abzuleiten wäre nicht zu empfehlen. Es würde zur undurchschaubaren Mehrfachvererbung führen. Ich gehe mal davon aus, daß dieses DB-Objekt sich um alles kümmern soll, was mit Datenbank zu tun hat. Es gibt ja noch die Möglichkeit, für jede Tabelle ein eigenes DB-Objekt anzulegen. So könnten die Daten im Rechner zwischengespeichert bleiben. Doch eigentlich sollte ja die Datenbank sich um diese Performance-Sachen kümmern.
Damit du später leicht aufrüsten kannst, solltest du von vorneherein die Klassen so anlegen, daß die Trennung Client-Server ohne Umprogrammierung möglich sein wird! Die einen Klassen bleiben dann auf dem Client, andere wandern zum Server.
Achte auf Einhaltung von MVC!

Klingt irgendwie alles logisch...

Aber MVC sagt mir nix...

M ... Model: die Business-Logik, die eigentlich möglichst nahe an der Datenbank programmiert werden sollte.

V ... View: die Benutzeroberfläche

C ... Controller: die Events, wenn Tasten gedrückt werden etc.
Hier wird auch eine Fehlermeldung angezeigt, wenn falsche
Eingaben getätigt worden sind.


Wenn du diese Trennung beachtest und einhältst, hast du bei Änderungen den geringsten Aufwand. Du könntest bspw. die Benutzeroberfläche ändern, ohne daß du bei M oder C etwas ändern müßtest. Meistens wird V und C ineinander verschmolzen, weil sie doch nahe zusammengehören. Doch VC sollten nichts davon wissen, wie die Daten abgespeichert werden. Es ruft lediglich Methoden von M auf, um Plausibilitätsprüfungen in der DB durchzuführen oder Daten zu lesen und abzuspeichern.
Es wäre eben umständlich, wenn in den Klassen von V oder C selbständig SQL-Abfragen generiert würden, die Daten aus der DB holen und Berechnungen durchführen. So etwas gehört nach M. Dann hast du es später viel einfacher bei Änderungen.

Danke für die ausführliche Erklärung! Das ist eigentlich eh die Kapselung von der OO.
Ich werde einfach eine Datenklasse schreiben, welche verschiedene Funktionen für die Ansichten zur Verfügung stellt (Rückgabe der Tabellen und Ansichten). Ist glaub ich am einfachsten...

Danke

du solltest auf jeden fall den db-zugriff vor den anderen klassen verbergen - sprich eine klasse (.. eine db-fassade) schreiben, die dir die erzeugung der objekte aus der datenbank und das schreiben dieser objekte abnimmt



als beispiel: du hast willst ein kundenobjket von dem du zb die id kennst, dann schickst du der db-fassade ein
get(Class.forname("Kunde"), id)
und die fassade leitet dann die nötigen schritte ein um ein solches objekt aus der db zu holen
(das Class.forname("Kunde") kannst ja weglassen und einfach getKunde(id) verwenden)

In .NET gibts da die tollen DataSets und DataTables und DataRows mit DataColumns... ;)

Mit denen kannst auf jede Datenbank gleich zugreifen :)