Verwendet jemand von euch ein Datenmodul? Erfahrung

[mkinzler]

Da Objekte in den Formularen u.U. Bezug auf Objekte in den DatenModulen nehmen.

[Kevin]

Ja, sorry , klingt logisch... Danke

[Hansa]

Die Frage kommt daher, weil man tatsächlich ein Datenmodul nicht unbedingt braucht. Dann kommen aber einige gewichtige ABER ! Am Anfang hatte ich ein Datamodul. Das diente nur der Übersichtlichkeit. Dann kam ein zweites dazu. Warum ? Ein zweites Programm überschneidet sich mit dem ersten aber nicht in allem. Also habe ich das verteilt. Dann kam das dritte, weil das 2. Programm eine zusätzliche Datenbank braucht. Ab 500-1000 Zeilen wirds in jeder Unit eng und unübersichtlich. Das gilt auch für Datenmodule. Deshalb gibt es jetzt auch ein viertes, welches nur strored Procedures enthält. Die werden allerdings auch von zwei Programmen genutzt. Insofern wird das auch noch aufgeteilt werden. Dann ist noch ein drittes Programm in Planung und wird sicherlich auch ein eigenes Datenmodul erhalten. Databases, Transactions sind allerdings immer nur zentralisiert in einem Datenmodul enthalten. Die Empfehlung, Datenmodule zu verwenden hat noch mehr gute Gründe : man stelle sich mal vor, allen Datasets eine andere Transaction zuzuweisen. Was ist zu tun ? Entweder alle Forms suchen, die ein Dataset haben und es umändern. Ich würde in einem solchen Fall hingehen und die betroffenen Datasets im Datamodul markieren (im OI steht 22 Objekte ausgewählt) und das dort ändern. Das nächste ist der Ort der Datenbank. Wo wird denn der festgelegt ? Irgendwo in einer Form ? Es hindert einen ja auch keiner daran, ein ganzes Programm in eine Unit zu legen. Ich mache das so :

Delphi-Quellcode:

procedure TDM.DataModuleCreate(Sender: TObject);
var Ini : TIniFile;
begin
  Ini := TIniFile.Create (ExtractFilePath (ParamStr (0)) + 'DB.INI');;
  if not CDStart then
    DBName := Ini.ReadString('Datenbank-Ort','DBName',ExtractFilePath (ParamStr (0))+'db\db.fdb')
  else
    DBName := ExtractFilePath (ParamStr (0)+'db\db.fdb');
  DM.DataBase.Close;
  DM.DataBase.DatabaseName := DBName;
  DM.DataBase.Open;
  DM.Transaction.Active := true;
  Ini.free;
end;

Diese Prozedur steht einem aber nur in einem Dadamodul zur Verfügung. Dem Programm ist es dabei sogar egal, wenn es von CD gestartet wird. In den Schreibroutinen der Datenmodule wird dann eben auch die Variable CDStart berücksichtigt. Daß die Datenmodule vor der ersten Form erzeugt werden sollten wurde ja bereits gesagt. Es dürfte wohl jeder hinkriegen die paar Zeilen in der DPR anders anzuordnen.

[alzaimar]

Zitat von Hansa:

Delphi-Quellcode:

procedure TDM.DataModuleCreate(Sender: TObject);
...
  DM.Transaction.Active := true;
...
end;

Ist das cool , eine Transaktion im DataModuleCreate zu starten.
Aber nur, wenn man ein Eremit ist

Aber mal was zum Thema:

Datenmodule sind ja nicht nur Container für TDatasets etc., sondern in der klassischen Softwareentwicklung für die Verwaltung der Anwendungsdaten zuständig. So gesehen ist jede Klasse auch irgendwie ein 'Datenmodul'. Ich kann dieses Paradigma bei DB-Anwendungen nun nutzen, um mit einem TDatamodule meine Daten zentral zu verwalten. Aber ich würde schon, wenns komplexer wird, für jeden Metatyp ('Kunde', 'Artikel') ein eigenes Datenmodul implementieren. Das ist natürlich Quatsch, wenn der 'Kunde' nur aus einer Tabelle besteht, aber ich bastel gerade an einem Projekt, wo es ca. 20 Tabellen sind. Dann macht das durchaus Sinn, ein TCustomerDatamodule zu schreiben.

[Hansa]

Was cool, Eremit ? Ich stelle lediglich sicher, daß folgendes nicht zu sehen ist : "...because Transaction is not active" Es gibt sogar Leute, die jedem Dataset eine eigene Transaction zuweisen. IMHO haben die das Transactio-Prinzip des alles oder nichts nicht richtig verstanden. Oder sie suchen ihr Heil in der Flucht. Was hindert Dich denn dran 20 Tabellen ein und derselben DB in einem Datenmodul zu verwalten ? Theoretisch genügt ja sogar ein Dataset für alles, sofern es richtig zusammengebaut wird. Oh Gott. Nicht, daß das tatsächlich jemand macht

[Elvis]

DataModules ermögliches es visuell eine nichtvisuelle Klasse zusammenzuklicken.
Ide Verknüpfung mit anderen dataModules/Forms/Frames sollte man aber einfach ignrieren. Da erkauft man sich Faulheit mitekligen Nebeneffekten. Delphis klassenübergreifende Verknüpfungen im designer basieren nur auf globalen Variablen.ein effekt von solch barbarischen Methoden dürfte davar bereits erlebt haben.
DataModules lasen sich aber als Komponente auf's Form ziehen, dort ein paar Properties anpassen und zur Laufzeit macht es dann was man will. Ohne dass man auf sowas achten muss:

• Zitat:

  Zu beachten ist die Erstellungsfolge !!! Datamodule müssen vor den anderen Formularen erzeugt werden !!!

• Zitat:

  Habe aber oft Probleme damit, weil z.B. das Formular vor dem Datenmodul erstellt wird und trotzdem darauf zugreifen muss.

• Zitat:

  Was man vermeiden sollte: In visuellen Formularen Filter setzen und diese nicht mehr aufheben beim Formular schliessen.

Diese "RAD über alles" Philosophie manches Delphisti dürfte einiges an Wartbarkeit opfern und vor allem, auf die gesamte Entwicklungszeit betrachtet, das R aus RAD aufheben.

btw: Hansa ist ja wieder in Höchstform...

[sir-archimedes]

Ich möchte diese Diskussion noch einmal etwas aufflammen lassen. Ich habe für ein aktuelles Projekt (ca. 20 Tabellen) bewusst vor, möglichst wenig in DataModules zu legen. Bislang habe ich konzeptionell zusammengehörige DataSets immer in einem DataModule verwaltet. Das sind dann für ein Projekt mehrere solcher Module (Allgemein, Kunden, Aufträge, Rechnungen, etc.) Das ist aber an vielen Stellen auch relativ unübersichtlich geworden. Vor allem ist es doof, wenn (durch einen Fehler) mehrere Formulare die gleichen DataSets ungewollt verwenden. Das führt zu schlecht reproduzierbaren Fehlern, die man nachher sehr schwer finden kann.

Ich mache das jetzt so: ich nutze einen "Applikations-Server" (RemObjects/DataAbstract), dann für jedes konzeptionell zusammengehörige Modul ein DataModule, in dem ich dann Dinge, wie Imagelisten, Verbindungskomponenten zum App-Server, etc. verwalte. Die Formulare haben dann die DataSet-Komponenten direkt auf sich selbst liegen. Dadurch habe ich eine vollständige Entkopplung zwischen den verschiedenen Formularen. (Gemeinsam zu nutzende DataSets kann ich immernoch in das DataModule legen) Ich fand es einfach zu unübersichtlich, 40 DataSets in einem DataModule liegen zu haben + verschiedene Eventimplementierungen.

Ich könnte natürlich auch für jedes Formular ein DataModule erstellen, welches dann immer zur Laufzeit erstellt und zerstört wird. Aber das finde ich auch nicht wirklich elegant. Vor allem hört sich das sehr unperformant an.

Was meint ihr dazu?

[Hansa]

Hört sich viel zu kompliziert an. Du testest doch die Objektablage. Wenns richtig gemacht sein soll, dann spielt die bei so was mit. Bei mir liegen die Haupt-Datasets im DataModul. Beispiel : Statistik-Dataset ist im Datamodul. Nun brauche ich allerdings auch Vorjahresstatistiken. Hierzu auch ein weiteres Stat-DS. Aber nur für solche Fälle. Das liegt nun aber nicht auch noch im DataModul, sondern auf derjenigen Urform, die ich in mehreren Stufen sowieso an die verschiedenen Vorjahresstatistiken per Objektablage weitervererbe. Das eine Statistik-Dataset liegt deshalb im Datamodul, weil ich es auch zum Speichern benutze. Dazu brauche ich aber keine zwei.

Nun kann ich aber für besagte Vorjahresstatistiken das aus dem DataModul für das eine Jahr verwenden und das zweite für das andere Jahr und fertig. In diesem Fall braucht man nur die Selects dieser beiden Datasets anzupassen. Die Objektablage ist nun aber zusätzlich dazu gut geeignet in der Hierarchie sonstige Steuerelemente EINMALIG unterzubringen. Z.B. eine CheckBox "Monate aufaddieren" Edits "von/bis Monat ,Jahr". Die Urform der Statistik enthält hierbei nur ein paar Panele und eben das Vegleichsjahr-Dataset. Die nächste Form wird um von/bis Edits für Zeitraum erweitert. Soll es eine Artikel-Statistik werden, dann vererbe ich aus der Objektablage die Form mit den von/bis-Edits und füge dann lediglich "von/bis Art.Nr." lblEdits hinzu. Das Dataset ist ja bereits von der Urform bekannt. Letztenendes sieht die Form-Deklaration dann so aus :

Delphi-Quellcode:

uses DM;  // erstes Statistik-Dataset aus DataModul hier für ein Jahr benutzen, deshalb : einbinden
...

  TfrmStat = class(TForm)
    pnlOben: TPanel;           // für jede Statistik benötigt : direkt hier deklarieren
    pnlMitte: TPanel;
    pnlUnten: TPanel;
    lblDatum: TLabel;
    lblStationNr: TLabel;
    lblUeberschrift: TLabel;
    sbArtNrAus: TStatusBar;
    btnEnde: TButton;
    VerglDS: TpFIBDataSet;     // in Abkömmlingen für Vorjahreswerte
                              
//  Aussehen und Erreignisse zentralisieren:

    procedure FormShow(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
    procedure FormKeyDown(Sender: TObject; var Key: Word;
      Shift: TShiftState);
    procedure FormCreate(Sender: TObject);
    procedure btnStartClick(Sender: TObject); // ACHTUNG ! Enthält Ausgabe (virtual) !!
  protected
...
  end;

--> nach und nach immer mehr Controls eingefügt, irgendwo verzweigen mit TChart / Stringgrid

  TfrmArtChartStat = class(TfrmVonBisChartStat)
    edVonArtNr: TlblIntEdit;
    edBisArtNr: TlblIntEdit;
    gbArtNr: TGroupBox;      // enthält Art.Nr.-Edits 
    procedure gbArtNrExit(Sender: TObject); // falls von > bis Werte hier tauschen
    procedure FormShow(Sender: TObject);
  protected
    VonArtNr,
    BisArtNr : integer;
  end;

Man schaue sich mal die mickrige Deklaration der unteren Form an. Die enthält aber schon alles !!

[sir-archimedes]

Ja, ich beschäftige mich (eigentlich ziemlich begeistert) mit der Objektablage. Grundsätzlich ein wunderbares Konzept. Ich werde dieser Mail mal einen Screenshot eines Datenmodules anhängen, das in einem Projekt entstanden ist. Und es ist nur ein Datenmodule von mehreren. An dieser Stelle kann ich einfach nicht mehr von Ordnung sprechen. Vor allem hat man auch keine Übersicht mehr, wenn man jetzt die Ereignisbehandler für die ganzen DataSets zentral halten möchte...

Daher bin ich ganz froh, nun dieses angesprochene DataAbstract zu benutzen. Dabei kann ich nämlich alles an SQL-Abfragen zentral verwalten und muss keine Queries, etc. mehr anpassen. Ich wähle jetzt quasi nur noch aus, welche der vorher definierten Abfragen ich in meiner Form verwenden möchte. Daher habe ich damit keine großen Übersichtlichkeitsprobleme.

Ich glaube einen Zwischenweg zwischen "nur DataModule" und "kein DataModule" zu finden ist das Optimum und das ist mein Ziel Meines Erachtens ist eine gute Kapselung von Features, die sich meine Forms teilen - durch die Objektablage und Auslagerung von Basisforms ohne Controls in Packages - wichtiger und hält den Wartungsaufwand stärker in Grenzen. Oft kommt ja doch mal ein Feld im Nachhinein dazu, durch das ich ein paar Queries verändern muss. Das kann man natürlich gut in einem DataModule. Aber meistens ändert sich auch etwas an der Oberfläche (das Feld will ja gepflegt werden). Daher muss ich so oder so auch an die Form heran - die Kapselung des DataSets im DataModule hat also hierfür wenig gebracht.

So, ich bin jetzt auch mal erst mal wieder raus und mache mal mit meiner Objektablage weiter

Gruß,
Dominik

[squetk]

Für kleinere Projekte ist ein Datenmodul uneingeschränkt zu empfehlen - für richtig grosse jedoch nicht.
Ich habe hier ein Programm noch in Pflege, das über 100 Tabellen benötigt. Es wurde von mir vor ca. 10 Jahren erstellt und hat "nach Lehrbuch" alle Abfragen und Update-/Insert-/Delete-Statements in Querys und die in mehrere Datenmodule verfrachtet.

Das ganze ist extrem unübersichtlich und deshalb ausserordentlich schlecht wartbar.

Die Lösung für grosse Projekte ist für mich seit einigen Jahren eine Kombination aus drei Bausteinen:

1. einer abstrakten Datenbankklasse, die mich von allen Updatequeries befreit und nebenbei die Struktur der Tabellen automatisch pflegt und beim Kunden anpasst,

2. einer Klasse, die als eine Art "Wörterbuch" fungiert und für alle Felder der Datenbank die Eigenschaften speichert und damit

3. einer eigenen Dataset-Komponente alle Konfigurationsinfos liefert (nie wieder mühevoll immer und immer wieder die gleichen persistenten Felder im OI konfigurieren)

Die SQL-Abfragen für Statistiken etc. sind grösstenteils in der Datenbank selbst gespeichert und damit ohne Programmneukompilierung anpassbar.

Ein Datenmodul habe ich immer noch - da befinden sich aber nur noch eine Handvoll Komponenten wie die Database, Transaction und eine ImageList.