Best practices: DataModules und Datenbankzugriff

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
Antworten
markusd112
Beiträge: 24
Registriert: Do 30. Aug 2012, 16:57

Best practices: DataModules und Datenbankzugriff

Beitrag von markusd112 »

Hallo,
an manchen Stellen las ich eine Arbeitsweise, möglichst alles in verschiedene DataModules auszulagern, z.B. ein DataModule nur für die Connection, dann jeweils eines für jede Datenbanktabelle usw.

Ich finde das ziemlich unübersichtlich. Spricht irgendwas dagegen, alle datenbankspezifischen Objekte in ein einziges DataModule zu packen? Haben die DataModule-Objekte sonst noch irgendeinen praktischen Nutzen, außer dass sie für die IDE notwendig sind, damit sie dort grafisch dargestellt werden?

Danke und Gruß

markusd112

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Re: Best practices: DataModules und Datenbankzugriff

Beitrag von Christian »

Das kommt auf deine Anwendung an. Wenn du "Objekte" hast die du mehrfach brauchst z.b. Adressen, die du in mehren Tabs darstellen kannst. Ist es natürlich besser die Datenbankkomponenten für die Adresse auf das Formular des Tabs zu packen.
Für global genutzte Tabellen wie z.b. Anreden Mengeneinheiten u.s.w. wäre ein Datenmodul die bessere Wahl.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

markusd112
Beiträge: 24
Registriert: Do 30. Aug 2012, 16:57

Re: Best practices: DataModules und Datenbankzugriff

Beitrag von markusd112 »

Christian hat geschrieben:Das kommt auf deine Anwendung an. Wenn du "Objekte" hast die du mehrfach brauchst z.b. Adressen, die du in mehren Tabs darstellen kannst. Ist es natürlich besser die Datenbankkomponenten für die Adresse auf das Formular des Tabs zu packen.


Aber nicht unbedingt: ich kann doch alles in meine DataModule-Unit packen und von dort aus in den jeweiligen Formularen einbinden. Dann habe ich alles, was mit Datenbankzugriffen zu tun hat, an einer Stelle. Ich würde dann vielleicht sogar soweit gehen, kein DataModule zu verwenden, sondern ggf. ein richtiges GUI-Formular, um z.B. die Datenbankeinstellungen darüber vornehmen zu können...

Oder hat das DataModule sonst irgendwelche Vorteile, die ich bei einem klassischen TForm nicht habe?

[/quote]Für global genutzte Tabellen wie z.b. Anreden Mengeneinheiten u.s.w. wäre ein Datenmodul die bessere Wahl.[/quote]

Ja, das stimmt. Ich persönlich würde (wie oben geschrieben) aber dann bevorzugen, alles zentral dort zu hinterlegen, ansonsten hat man doch wieder alles verstreut in mehreren Formularen...

Sorry, für diese Anfängerfragen, aber ich arbeite mich gerade ein wenig in das Thema ein und möchte nach Möglichkeit gleich am Anfang alles möglichst gut machen, um nicht mittendrin festzustellen, dass ich es vielleicht doch besser alles woanders reingepackt hätte :D

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Best practices: DataModules und Datenbankzugriff

Beitrag von mse »

Ein Datamodule kann als "business object" dienen. Bei mir gibt es meistens ein "mainmodule" mit DB-connection und TAction und ifi-Komponenten für die Applikationssteuerung und einzelne Datamodule zur Bedienung der zugehörigen Edit- und Ausgabe Formulare.
Die Formulare enthalten ein oder mehrere TDataSource und/oder ifi-Komponenten als Interface zu den Entsprechenden Datamodulen. Formulare enthalten aber keine TDataset und kein Code für die business logic, das ist alles in den Datamodulen.
Damit lassen sich RAD und Trennung von GUI und Applikation perfekt kombinieren.
Meistens erben Edit-Listen und -Dialoge von gemeinsamen Basisformularen mit den immer benötigten Grundfuntionen (Datasource, Dbnavigator, TStatFile, Erstellungs- und Änderungs-timestamp-Anzeige...)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Re: Best practices: DataModules und Datenbankzugriff

Beitrag von Christian »

@markus. Lies bitte meine Antwort. Ich habs dir sogar mit nem Beispiel erklärt und du fragst das selbe was ich erklärt hab nochmal.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

markusd112
Beiträge: 24
Registriert: Do 30. Aug 2012, 16:57

Re: Best practices: DataModules und Datenbankzugriff

Beitrag von markusd112 »

mse hat geschrieben:Ein Datamodule kann als "business object" dienen. Bei mir gibt es....

Danke für den Blick in die Praxis, wie Du es machst! :D

Christian hat geschrieben:@markus. Lies bitte meine Antwort. Ich habs dir sogar mit nem Beispiel erklärt und du fragst das selbe was ich erklärt hab nochmal.

Ich hab das schon gelesen, glaube eher, wir reden aneinander vorbei. :wink: Mir ging es um die Frage, ob es sinnvoll ist, jede Kleinigkeit in getrennte DataModules und Units zu verteilen, oder ob man nicht lieber ein (oder zwei) große Units (und damit weniger Sourcecode-Dateien) erstellt mit den datenbankrelevanten Dingen (von mir aus dort dann mehrere TDataModule Klassen für verschiedene Aufgaben). Wenn ich jede Kleinigkeit in separate Units packe, hat man ja einen "Verhau" an Includes...
Dabei interessierte mich auch, welche Funktionen/Vorteile mir eine TDataModule Klasse bietet oder was dafür spricht, z.B. jede Datenbank-Tabelle in eigene, separate TDataModul Klassen zu packen, oder einfach alles in ein TDataModul...

Gruß

markusd112

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Re: Best practices: DataModules und Datenbankzugriff

Beitrag von Christian »

Ich hatte das früher mal so das ich alles in ein Datenmodul gepackt habe. Allerdings begrenzt man sich damit zu schnell selbst deshalb hab ichs dann gelassen.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Best practices: DataModules und Datenbankzugriff

Beitrag von mse »

Hier zur Illustration Screenshots von MSEkicadBOM, ein Programm mit Komponentendatenbank und Fabrikationsdateiengenerator für KiCad welches gerade am entstehen ist:
https://gitlab.com/mseide-msegui/mseuni ... /kicad/bom
Das Hauptmodul:
mainmo.png

Das Hauptformular:
mainfo.png

Basis-Editformular:
base.png

Abgeleitetes Record-Edit-Formular:
component.png

Antworten