[Diskussion] Effektivste Methode Daten aus DB ins Programm

[RWarnecke]

Ich habe mir die Links angeschaut. Vom theoretisch Teil her, habe ich es soweit verstanden. Nur mir fehlt ein Ansatz, wie ich das OPF umsetzen soll. Eine meiner ersten Ideen war es, Klassen zu schreiben für die unterschiedlichen Bereiche, welche mir die Daten aus der Datenbank zur Verfügung stellen, was ich aber für etwas umständlich halte. Deshalb brauche ich da von euch mal ein paar Denkanstöße, wie ich so ein OPF in Programmcode umsetzen kann.

[guidok]

Hallo Rolf,

ich sehe jetzt zwei Möglichkeiten: Entweder du programmierst dir das grundlegende Framework selbst und erstellst auf dieser Basis deine benötigten Business Objects oder du verwendest eine bereits fertige Lösung (siehe letztes Post) und implementierst darauf deine BO's.

Bei der zweiten Lösung hast du zwar weniger Hintergrundwissen, was im OPF passiert, du wirst allerdings schneller zu einer funktionstüchtigen Anwendung kommen und kannst davon ausgehen, dass das OPF fehlerfrei ist (wenigstens weitgehend).

Ansonsten sollte alles klar sein. Du musst zunächst die Business Objects erstellen (z.B. BO Kunden für Kundenstammdaten), welche dir die benötigten Daten (und entsprechende Logik) für deine GUI oder Reports bereitstellen.

Guido

[hanspeter]

Hallo,

ich verwende für solche Aufgaben IBDAC.
Das gibt es als Unidac auch für mehrere Datenbanken.
In diesem Framework setzt eine Query auf einem Memorydataset auf.
Die Query hat einen Disconnect Mode. D.h. Daten werden nach dem Einlesen persisistent im Speicher gehalten und
Updates/Inserts im Cache gehalten.

Also folgender Ablauf:

Connect
Lese Datensatz
Disconnect

Den Datensatz bearbeiten.

Dann Abfrage ob Update/Insert notwendig ist.
Wenn ja dann

Connect
ApplyUpdates
Disconnect

Diese Lösung hat den Vorteil, das ich im Programm mit datensensitiven Componenten arbeiten kann.

Datenmengen stelle ich in einem Grid dar, welches sich aus einer Query selbst initialisiert und dann die
Auswahl ohne Datenbankverbindung darstellt.
Das Grid handelt das Read/Update selbst.
Objecte wie z.B. KundenClass oder ArtikelClass melden sich bei der Datenbankschicht an (Observer) und werden dann
bei Änderungen automatisch gefüllt.
An diesem Teil arbeite ich im Moment noch.


Gruß
Peter

[Sherlock]

Ich verwende keine TTables, die seien inperformant habe ich mir mal sagen lassen. Die klassische Kombination aus TDataSet und TDataSource tun ihren Dienst bei Datengebundenen Komponenten, und für die eine oder andere Abfrage zwischendurch gibts TQuerys. Ist kein Hexenwerk, kein Vorbild an OOP, aber es läuft, und es läuft schnell.

Für mich haben Zwischenschichten das Problem, daß sie zwar hübsch modern sind, aber wenn man etwas dran tun muß, das über Optimierung hinausgeht dann muss man das in der Regel in allen Schichten gleichzeitig tätig werden.

Just my 2 cents.

Sherlock

[RWarnecke]

Zitat:

Zitat von guidok

ich sehe jetzt zwei Möglichkeiten: Entweder du programmierst dir das grundlegende Framework selbst und erstellst auf dieser Basis deine benötigten Business Objects oder du verwendest eine bereits fertige Lösung (siehe letztes Post) und implementierst darauf deine BO's.

Bei der zweiten Lösung hast du zwar weniger Hintergrundwissen, was im OPF passiert, du wirst allerdings schneller zu einer funktionstüchtigen Anwendung kommen und kannst davon ausgehen, dass das OPF fehlerfrei ist (wenigstens weitgehend).

Wenn möchte ich schon wissen, was mein OPF macht. Dazu hatte ich den Gedanken, dass ich alles in einem Datenmodul packe und diese Unit halt immer dann einbinde, wenn ich den Zugriff auf die Datenbank brauche. In dem Datenbankmodul sind dann alle Funktionen für die verschiedensten Abfragen/Insert/Updates vorhanden. Ich erreiche damit aber auch kein richtiges OPF oder sehe ich das falsch ?

Zitat:

Zitat von guidok

Ansonsten sollte alles klar sein. Du musst zunächst die Business Objects erstellen (z.B. BO Kunden für Kundenstammdaten), welche dir die benötigten Daten (und entsprechende Logik) für deine GUI oder Reports bereitstellen.

Das ist schon mal ein guter Hinweis, denn ich zerbreche mir gerade den Kopf darüber, wie und wann ich etwas erstelle.

Mein Ziel ist es eine gesunde Mischung zwischen einer effektiven Anwendung und einer einfachen wartbaren Anwendung zu finden. Das heißt für mich, ich brauche auf jedenfall ein OPF.

[DeddyH]

Hallo Rolf,

im Moment hab ich nicht soviel Zeit, aber ich könnte heute Nachmittag einmal meine Gedanken zum Aufbau so einer Anwendung posten, das dürfte aber ein längerer Post werden :mrgreen:

[guidok]

Ich habe gerade noch etwas gefunden. Bin mit dem Durchlesen noch nicht fertig, aber könnte interessant sein...

[DeddyH]

So, wie angedroht hier einmal die Gedanken, die ich mir gemacht hatte. Was ich letztendlich erreichen wollte war, dass das Frontend mit "ganz normalen" Klassen hantiert und nichts von der DB weiß bzw. wissen muss. Ein "fertiges" OPF wollte ich allerdings nicht benutzen, da diese entweder zu unflexibel oder zu kompliziert sind und ich außerdem die Kontrolle behalten wollte.
Fangen wir mal "unten" (bei der Datenbank) an. Nach einem größeren Kraftakt resultierend aus einer DB-Umstellung bin ich auf den Trichter gekommen, zur Kommunikation zwischen OPF und DB ausschließlich auf Views und SPs zurückzugreifen. Man kann das auch dahingehend auf die Spitze treiben, dass man alle Rechte auf die Tabellen entzieht und nur diesen Views und SPs erteilt. Nehmen wir als Beispiel einmal an, wir möchten Personen mit ihrer Augenfarbe (eigene Stammdatentabelle) erfassen. Dann könnte die View beispielsweise so aussehen (schnell aus dem Kopf getippt, keine Garantie für Funktion):

SQL-Code:

CREATE VIEW VW_Person(ID,Name,Vorname,AugenfarbenID,Augenfarbe)
AS
  SELECT
    Person.ID AS ID, 
    Person.Name AS Name, 
    Person.Vorname AS Vorname, 
    Augenfarben.ID AS AugenfarbenID,
    Augenfarben.Bezeichnung AS Augenfarbe
  FROM
    Person
  JOIN 
    Augenfarben ON Person.Augenfarben_ID = Augenfarben.ID

Dazu kommen dann noch 3 SPs (je eine zum Einfügen, Ändern und Löschen). Die entsprechende Klasse im OPF hätte dann die entsprechenden Properties, die aus der View gefüllt und mittels SP geändert werden. Zusätzlich habe ich noch Objektlisten implementiert, um z.B. eine Auswahl per ComboBox zu ermöglichen.

Delphi-Quellcode:

TPersonenliste.GetPersonen(const sList: TStrings);

Dabei werden die entsprechenden Objekte mittels AddObject sofort in den Items hinterlegt (kann man auch anders machen, wenn man den Speicher schonen will oder voraussichtlich sehr viele Datensätze erwartet). Nun ist es am Frontend relativ leicht, einen Datensatz zu holen und zu bearbeiten: aus den Items z.B. einer ComboBox den entsprechenden Satz auswählen, in die Detailansicht wechseln, bearbeiten und abspeichern. Die SPs, die dahinterstehen, müssen mich hier überhaupt nicht mehr interessieren, wenn sie einmal ordentlich durchgetestet sind.

So mache ich das im Moment (ist ja immer noch in der Entwicklung), ob das der Königsweg ist, kann ich nicht entscheiden, aber es funktioniert bislang überraschend gut ;)

[guidok]

@DeddyH:

Der größte Nachteil den ich sehe ist, dass du durch die Views und SP sehr dicht an der DB arbeitest. Ein Wechsel der DB oder das Speichern z.B. in XML wird damit sehr schwierig...

Ich weiß aus eigener leidvoller Erfahrung, dass was in MSSQL funktioniert, in MySQL völlig anders ist.

[DeddyH]

Das gebe ich zu, ist aber auch nicht vorgesehen.