Dynamisch erzeugte Datenmodule

[urs.liska]

Hallo,

ich habe eine Frage, die mit dem ökonomischen und sinnvollen Design einer Datenbankanwendung zusammenhängt.
Ich arbeite an einer Datenbank, die mich seit längerem begleitet und wohl auch noch einige Zeit wichtig sein wird.
Ich hatte sie zunächst als Paradox-DB angelegt und auch eine halbwegs funktionierende Anwendung dazu geschrieben (und dabei Delphi gelernt). Jetzt habe ich eine neue, erweiterte Firebird-DB daraus gemacht(mit ca. 40 Tabellen) und die Daten auch schon übertragen.
Da es nun doch eine etwas größere Sache ist, möchte ich die neue Anwendung sorgfältiger planen und möglichst sinnvoll mit Vererbung arbeiten, um einheitliches Verhalten und Aussehen sowie leichtere Wartbarkeit zu erreichen.

Für die Bearbeitung der Daten möchte ich folgende Konstruktion erreichen:
1) Ein Formular, das die ganze Tabelle in Auszügen (typischerweise ein Schlüsselfeld und ein Erkennungsfeld (z.B. Autor und Titel bei einer Literaturliste)) darstellt (abgeleitet von einer Klasse TCustomDatasetForm). Hier kann z.B. ein bestimmter Datensatz gesucht werden oder eine Selektion für einen Export durchgeführt werden.
2) Eine weitere Formularklasse, die eine Maske für jeweils einen Datensatz bereitstellt (abgeleitet von TCustomRecordForm).
3) Ich möchte dazu jeweils Datenmodule verwenden (Zwecks Trennung von Design und Inhalt).
4) Es sollen beliebig viele Datensätze (also Formulare) geöffnet sein können. Daher verwaltet das Tabellenformular 1) eine Liste der geöffneten Datensatzformulare, so dass ich etwa eine solche Methode verwenden könnte:

Delphi-Quellcode:

function TCustomDatasetForm.Edit(AKey: integer): boolean;
var rf: TCustomRecordForm;
begin
  result := false;
  rf := RecordForm(AKey); { gibt das Datensatzformular oder nil zurück, = Prüfung, ob der Datensatz bereits offen ist }
  if rf = nil then
  begin // Datensatz erzeugen, in Liste einfügen und anzeigen
    rf := FRecordFormClass.Create(Self); //FRecordFormClass wird im Konstruktor gesetzt
    Datensaetze.Add(rf);
    rf.Edit(AKey);  // kümmert sich um die Anzeige des Formulars
  end
  else  // Datensatz schon offen, lediglich das Formular anzeigen
  begin
    if rf.visible then rf.BringToFront
    else rf.Show;
  end;
end;

Zu diesem Zweck benutze ich keine globale Variable für das Datensatzformular, sondern erzeuge es dynamisch.
Mit dem dazugehörigen Datenmodul könnte ich es genauso machen. Ich würde dafür ein Feld FDatenModul: TDataModule in die Datensatzformularklasse einbinden, so dass ich etwa folgende Aufrufe machen könnte:

Delphi-Quellcode:

constructor TVonCustomRecordFormAbgeleiteteKlasse.Create(AOwner: TComponent);
begin
  inherited;
  FDatenModul := TDatenmodulFuerDiesenDatensatztyp.Create(Self);
  ...
  FDatenModul.MainDataSet.Active := true;
  ...
  FDatenModul.BeliebigeDortDefinierteMethode;
end;

Meine Frage ist jetzt, inwiefern ich dann noch in der IDE Zugriff auf das Datenmodul haben kann. Wenn ich ein datensensitives Steuerelement auf einem Formular ablege und im OI die DataSource etc. einstellen will, habe ich doch Zugriff auf alle Komponenten im selben Formular oder in Formularen/Datenmodulen, die ich über die uses-Klausel eingebunden habe (?), und letztere werden über ihre globale Variable angesprochen, die Delphi automatisch erzeugt (?).
Kann ich denn die visuellen Programmierhilfen beim Entwurf meines Formulars überhaupt in Anspruch nehmen? Ich will doch (soweit ich es verstehe) keine Verbindung der Steuerelemente mit dem globalen Datenmodulobjekt, sondern für jede Instanz des Formulars mit dem jeweils dynamisch erzeugten Datenmodul. Oder habe ich da etwas ganz falsch verstanden?
Ich könnte mir vorstellen, auf die Datenmodule zu verzichten; letztlich ließe sich alles wohl auch innerhalb des Formulars realisieren (zumal die Erzeugung jeweils eigener Datenmodul-Instanzen auch Overhead mit sich bringt). Aber erstens scheint es mir ratsam, auch hier die Trennung von GUI und Datenbank-Logik aufrecht zu erhalten - und zweitens würde ich bei dieser Gelegenheit wirklich gerne einen Schritt mehr über OOP verstehen.

Es wäre klasse, wenn sich jemand die Mühe machen könnte, meine (zugegebenermaßen lange) Frage durchzulesen und mich auf den richtigen Weg zu bringen.

MFG
Urs

[woki]

Hallo,

um kurz darauf einzugehen: Also

1. Trennung von Gui, Businesslogik und Datenbankschichtunbedingt aufrechterhalten, alles andere wird man später bereuen.
2. Auch wenn ein Datenmodul zur Laufzeit dynmaisch erzeugt wird, kann man visuell designen, muß aber etwas aufpassen, daß die visuellen Komponenten dann auch mit den Datasets der richtigen Instanz des Datenmodules verbunden werden. Die Datasources sollten auf der Form liegen, und dann zur Laufzeit mit der entsprechenden erzeugten Instanz des Datemmodules verbunden werden.

[urs.liska]

Hallo,

danke erstmal. Ich werde mir das morgen früh nochmal zu Gemüte führen. Jetzt würde ich es nicht mehr ganz klar bekommen.
Aber ich glaube, es klingt plausibel für mich.

MFG
urs

[Lemmy]

Hi Urs,

klingt nach viel Arbeit.... woki gebe ich Recht, trenne Gui, Businesslogik und Datenbankschicht voneinander. Doch die DM würde ich auf keinen Fall dynamisch erzeugen. Schau Dir mal folgenden Artikel von Holger Klemt an, ich denke, das ist genau das was Du brauchst:

http://www.h-k.de/oop/artikel_oop.zip

In diesem Artikel beschreibt Holger Klemt, wie man auf eine Datenbank objektorientiert zugreift, d.h. für unterschiedliche Tabellen Zugriffsobjekte (z.B. TAdresse) baut, die alle Datenbankoperationen übernehmen.

Grüße
Lemmy

[urs.liska]

Hallo Lemmy,

vielen Dank für den Tipp. Es ist in der Tat erstaunlich, wie weitgehend dieses Tutorial meine Problemstellung widerspiegelt. Ich hatte auch schon die Idee, die Datenbankanbindung über eigene Objekte zu realisieren, hatte aber Bedenken, alle Steuerelemente von Hand zu programmieren und auf die Datensensitiven Steuerelemente zu verzichten (immerhin geht es um eine ganze Reihe von Formularen mit ziemlich vielen Tabellenfeldern). Nach der Lektüre lohnt es sich aber wohl doch, diesen Ansatz nochmals zu überdenken. Allerdings sind in dem Artikel (wohl der Kürze halber) keine komplexeren Beispiele, so dass ich mir schon überlegen muss, ob das auch durchzuhalten ist. Immerhin geht es mir nicht nur um die Darstellung von Tabellen, sondern auch von relativ komplexen Master-Detail-Beziehungen.
Mir kommt es außerdem ungewöhnlich vor, dass das Datenobjekt komplett die Steuerung des Formulars übernimmt, ich fände es näherliegend, wenn das Formular für seine Darstellung zuständig ist und dazu auf das Datenobjekt zugreift. Aber das werde ich noch genauer überlegen.

MFG und nochmals vielem Dank
Urs

[Lemmy]

Hi,

Zitat von urs.liska:

Mir kommt es außerdem ungewöhnlich vor, dass das Datenobjekt komplett die Steuerung des Formulars übernimmt, ich fände es näherliegend, wenn das Formular für seine Darstellung zuständig ist und dazu auf das Datenobjekt zugreift. Aber das werde ich noch genauer überlegen.

dann solltest Du dir das nochmal genau überlegen, denn genau da liegt der Vorteil (!!!) dieser Technik! Lös dich davon, dass das Formular das zentrale Element ist, um das Du deine Applikation baust. Ein Formular ist für die Interaktion mit dem User wichtig, aber nicht mehr und nicht weniger.

Beispiel: Ich entwickle z.Zt. ein Berechnungsprogramm fü die HOAI (Honorarordnung der Architekten und Ingenieure). Da gibt es 13 Teile (z.B. für Architekten, Bauingenieure, Vermesser), die sich in verschiedenen Bereichen (der Berechnung) wiederholen. Erst habe ich auch alles auf Formular - Unit Basis erzeugt, war der totale Reinfall! Inzwischen habe ich mehrere Basis-Klassen erzeugt, von denen ich immer vererbe. Inzwischen entwickelt sich die Applikation fast von alleine! In diesem Umfeld habe ich auch den Ansatz von Holger Klemt zumindest ein Stück weit umgesetzt, das funktioniert wunderbar!!
Anstelle von Select, Insert und Update-SQL verwende ich 2 Stored Procedures, eine zum holen von Daten und eine zum Schreiben. Wird die Berechnung das erste mal ausgeführt werden die Daten aus Stammtabellen geholt, beim zweiten Aufruf aus der Tabelle in der die Projektwerte gespeichert werden. Beim Speichern werden mittels Insert die Daten in die Projekttabellen geschrieben, sind die Werte schon vorhanden (beim 2. Durchlauf) werden diese mittels Update aktualisiert. Davon merkt die Applikation aber nix und der Aufruf ist immer derselbe!

Zitat von urs.liska:

Immerhin geht es mir nicht nur um die Darstellung von Tabellen, sondern auch von relativ komplexen Master-Detail-Beziehungen.

Da müsstest Du dir sicherlich den einen oder anderen Gedanken über die Darstellung / Behandlung dieser Daten machen. Kannst mir auch mal mailen, wenn Du nicht weiterkommst....

Grüße
Lemmy

[urs.liska]

Hallo Lemmy,

vielen Dank für den Nachdruck. Ich denke, Sachen wie solche sind es, die einen weiter bringen. Selbst wenn ich selbst über den Text von Holger Klemt gestolpert wäre, hätte ich es ohne jemanden, der aus Erfahrung darauf drängt, nicht so ernst genommen.
Mir scheint in dem Ansatz, die Darstellung des Formulars durch ein Datenobjekt erledigen zu lassen, jetzt auch eine Lösung für die Frage zu liegen, die Daten an verschiedene "Adressaten" auszugeben (z.B. ein Formular, aber auch eine HTML- oder php-Seite, aber die Frage habe ich nur für später im Hinterkopf, wenn ich die Ergebnisse meiner Arbeit vielleicht einmal ins Netz stellen will). Man könnte von einer Klasse, die die Business rules implementiert, weitere Klassen ableiten, die nur die Methoden zur Anzeige des Auswahl- und Bearbeiten-Formulars je nach Zielplattform implementiert...
Auf Dein Angebot, Dir Einiges mailen zu dürfen, werde ich vielleicht zurückkommen. Zuerst will ich mich aber selbst noch genauer damit auseinandersetzen (meine Frage und Eure Antworten kamen gerade noch rechtzeitig, bevor ich zu diesem Punkt tatsächlich Code geschrieben habe).

@woki: Auch an Dich nochmals vielen Dank. Auch wenn ich es jetzt wohl nicht so machen werde, habe ich doch etwas neues verstanden.

MFG
Urs