Best practices: DataModules und Datenbankzugriff
-
- Beiträge: 24
- Registriert: Do 30. Aug 2012, 16:57
Best practices: DataModules und Datenbankzugriff
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
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
-
- 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
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.
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/
-
- Beiträge: 24
- Registriert: Do 30. Aug 2012, 16:57
Re: Best practices: DataModules und Datenbankzugriff
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...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.
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

-
- 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
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...)
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...)
-
- 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
@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/
-
- Beiträge: 24
- Registriert: Do 30. Aug 2012, 16:57
Re: Best practices: DataModules und Datenbankzugriff
Danke für den Blick in die Praxis, wie Du es machst!mse hat geschrieben:Ein Datamodule kann als "business object" dienen. Bei mir gibt es....

Ich hab das schon gelesen, glaube eher, wir reden aneinander vorbei.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.

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
-
- 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
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/
-
- 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
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: Das Hauptformular: Basis-Editformular: Abgeleitetes Record-Edit-Formular:
https://gitlab.com/mseide-msegui/mseuni ... /kicad/bom
Das Hauptmodul: Das Hauptformular: Basis-Editformular: Abgeleitetes Record-Edit-Formular: