Verwendet jemand von euch ein Datenmodul? Erfahrung

[Karstadt]

Hallo. Für nicht visuelle objekte und für größere projekte wird ein Datenmodul empfohlen. Arbeitet jemand damit? Welche Erfahung. Ich kann mir nicht vorstellen das dieser Datenmodul die Arbeit wirklich erleichert.

Datei-Neu-Weiters-Datenmodul.

[sniper_w]

Ich habe es damals verwendet, als ich ein Lagerverwaltungsprogramm entwickelt habe. Ich denke, es ist gar nicht so schlecht, man hat eine seht guten Überblick über allen Tabellen, Datasets, Timers, AppEvents ets..., also all das, was nicht unbedingt etwas mit einem Formular zu tun haben muss.

[Karstadt]

dann muss aber dieser MODUL von anfang an Create sein und sich immer in Speicher befinden. Richtig?

[davar]

Also ich verwende ein Datenmodul und lege dort Datenbankkomponenten wie Tables, Datasources und Querys ab. Habe aber oft Probleme damit, weil z.B. das Formular vor dem Datenmodul erstellt wird und trotzdem darauf zugreifen muss. Bin bisher eigentlich davon ausgegangen, dass es an mir liegt, bin mir inzwischen aber nicht mehr sicher. Wenn es jemand besser weiss, wäre ich auch an einer Antwort interessiert.

Ich arbeite gerade an einem etwas größeren Projekt und überlege schon, ob ich die Komponenten doch wieder auf die Formulare verteilen sollte, auch wenn die Übersichtlichkeit darunter leidet..

MfG

davar

[Ferber]

Guten Morgen !

Zitat:

Zitat von Karstadt

Hallo. Für nicht visuelle objekte und für größere projekte wird ein Datenmodul empfohlen. Arbeitet jemand damit? Welche Erfahung. Ich kann mir nicht vorstellen das dieser Datenmodul die Arbeit wirklich erleichert.

Zitat:

Zitat von sniper_w

Ich habe es damals verwendet, als ich ein Lagerverwaltungsprogramm entwickelt habe. Ich denke, es ist gar nicht so schlecht, man hat eine seht guten Überblick über allen Tabellen, Datasets, Timers, AppEvents ets..., also all das, was nicht unbedingt etwas mit einem Formular zu tun haben muss.

@sniper_w: Vollkommen richtig !

Datenmodule sind für grössere Anwendungen wie Lagerverwaltung oder Warenwirtschaft unumgänglich notwendig !
Ausserdem gibt's Remote Datamodule für Client-Server Anwendungen.

Zu beachten ist die Erstellungsfolge !!! Datamodule müssen vor den anderen Formularen erzeugt werden !!!
Unter Projektoptionen die Erstellungsfolge ganz nach vorne, noch vor das Hauptformular !

Enorme Entlastung der restlichen Anwendung, Zentralisierung der Programmlogik.

Erreignisroutinen wie OnNewRecord, OnCalculate werden hier abgelegt. Das kann manchmal viel werden.

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

IMHO bester Datenbankzugriff: ADO.
Die BDE und Paradox bestenfalls für Einzelplatzanwendungen verwenden.

mfg Otto :)

PS: habt ihr gestern die Millionenshow gesehen ? Da wusste jemand nicht was EMOTICONS sind :mrgreen:

[aschne1]

Hi

Der Übersichtlichkeit zuliebe und wegen der Ereignismethoden der DB verwende ich auch bei kleinen Projekten immer ein Datenmodul. Vielleicht wird die Anwendung mit Zeit grösser und dann ist es recht mühsam alles wieder 'umzuordnen'.

Zitat:

IMHO bester Datenbankzugriff: ADO.

AnyDAC oder MyDAC?

Zitat:

Die BDE und Paradox bestenfalls für Einzelplatzanwendungen verwenden.

Die BDE würde ich bei neuen Projekten gar nicht mehr verwenden.

Gruss

[sniper_w]

Zitat:

Zu beachten ist die Erstellungsfolge !!! Datamodule müssen vor den anderen Formularen erzeugt werden !!!
Unter Projektoptionen die Erstellungsfolge ganz nach vorne, noch vor das Hauptformular !

Richtig. Das habe ich vergesen zu sagen.

[Karstadt]

Ja. Ist arbeite aber mit Form.Create, Form.Destroy. Wenn ich Form.Destroy aufrufe, werden alle objekte auf einen Formular enfernt und somit speicheradressen freigegeben. Wenn man aber mit Datenmodul arteitet dann werden alle z.B. 40 Objekte immer in Speicher befinden. Oder sehe ich das falsch?

[marabu]

Mit zunehmender Programmier-Erfahrung trachtet man nach einer größtmöglichen Entkopplung der Benutzerschnittstelle vom zugrunde liegenden Datenmodell. Dann verwendet man automatisch ein DatenModul. Zwar bleibt das Datenmodul für die Dauer der Programmlaufzeit instanziiert, doch gilt das nicht unbedingt für die enthaltenen Komponenten. Übrigens solltest du nicht Form.Destroy aufrufen, sondern Form.Free - siehe Online Hilfe.

Grüße vom marabu

[Kevin]

Zitat:

Zitat von Ferber

Zu beachten ist die Erstellungsfolge !!! Datamodule müssen vor den anderen Formularen erzeugt werden !!!
Unter Projektoptionen die Erstellungsfolge ganz nach vorne, noch vor das Hauptformular !

Auch wenn ich das immer so mache, kann mir einer kurz erläutern was für Vorteile das hat... :pale:

[mkinzler]

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

[Kevin]

Ja, sorry :oops: , klingt logisch... Danke :thumb:

[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:

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 :zwinker:

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 ? :shock: 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. :mrgreen: 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... :lol:

[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.