Sind "Datenmodule" noch aktuell?

[Neutral General]

Hallo,

Ich habe jetzt vor Kurzem wieder etwas von "Datenmodulen" hier in der DP gehört und auch wie
empfohlen wurde eins zu verwenden.
Ich selbst habe nie (weder in meinen 2 Semestern Informatik, noch in meiner Ausbildung) etwas davon gehört und kenne den Begriff und seine Bedeutung nur von Arbeitskollegen und dem Quellcode unseres Programms.

Daher frage ich mich ob diese "Datenmodule" überhaupt noch aktuell sind und verwendet werden oder verwendet werden sollten. Dazu kommt, dass ich selbst nichts davon halte, da Formulare für mich dazu da sind angezeigt zu werden und nicht um als Ablagefläche für Queries, Datasources o.ä. missbraucht zu werden.

Außerdem scheinen diese Datenmodule eine reine Erfindung der Delphi-Programmierer zu sein, da ich sowas noch in keiner anderen Sprache in der Art gesehen habe.

Deswegen die Frage:

Sind die Dinger noch aktuell?
Sollte man die benutzen?
Oder sind das einfach nur noch ein paar alte Hasen, die an dem was sie damals mal gelernt haben festhalten? (Nicht böse gemeint)

[guinnes]

Zitat:

Zitat von Neutral General (Beitrag 1147210)

Dazu kommt, dass ich selbst nichts davon halte, da Formulare für mich dazu da sind angezeigt zu werden und nicht um als Ablagefläche für Queries, Datasources o.ä. missbraucht zu werden.

Datenmodule sind keine Formulare, Datenmodule sind direkt von TComponent abgeleitet. Und Ja, ich benutze Datenmodule ständig, weil ich dann eine Stelle habe, an der die Daten bearbeitet werden.
Gegenfrage : Wo platzierst du den die Datenzugriffskomponenten ?

[divBy0]

Datenmodule verwende ich manchmal auch ganz gerne, ob was dagegen spricht weiß ich nicht, ich finde die aber nützlich.

[Nersgatt]

Ich persönlich nutze sie gar nicht und ich wüsste auch nicht wofür.
Z.B. SqlQueries kann man ganz wunderbar im Code instanzieren, genau da, wo man sie braucht. Dass man sich dann auch selbst ums Freigeben kümmern muss, ist klar. Aber nur um das einzusparen ein Datamodule zu nutzen?!? Nö, da ist mir die klare Struktur des Quellcodes deutlich wichtiger, als das bisschen Tipparbeit zu sparen.

[mkinzler]

In datenmodule kann man die Daten zentral für alle Formulare konfigurieren und ggf. so schnell tauschen, z.b. wenn man diesen in eine BPl o.ä auslagert.

[Uwe Raabe]

Ein paar Dinge, die oft besser in einem Datenmodul untergebracht werden, da sie dann von mehreren Forms/Frames/DataModules verwendet werden können:

• ImageList
• ActionList
• PopupMenu
• Database, Query, Table usw. je nach Datenzugriff

Datenmodule sind m.E. unerlässlich, um GUI und Businesslogik zu trennen, was auch das Testen (DUnit) deutlich vereinfacht.

Die Tatsache, daß es etwas nur in Delphi gibt und nicht in anderen Sprachen, ist mit Sicherheit kein Nachteil und auf keinen Fall ein Hinweis, etwas nicht zu verwenden.

[Sir Rufo]

Die Datenmodule sind doch nur eine logische Konsequenz vom RAD mit den Komponenten, die man auf eine Form klatschen kann.
Da es aber doof ist ein Formular zu benutzen, wo ich kein Formular benötige, man aber mit dem OI arbeiten möchte, benutzt man DatenModule.

Aus diesem Grund kann man auf so ein DatenModul auch keine visuellen Komponenten klatschen.

Niemand hindert einen daran, eine eigene Klasse dafür zu schreiben (meintetwegen abgeleitet von TComponent, wegen der automatischen Freigabe), aber das wäre dann nicht mehr RAD ;)

[p80286]

Bei mir verschwinden alle DB-Zugriffe in einem Datenmodul, wobei ich nicht an dem Namen "Datenmodul" hänge.
Wenn man sich ein wenig dabei gedacht hat sind diese DM leicht gegeneinander auszutauschen und ruckzuck für eine andere DB neu erstellt/angepasst.
Das ist "real live rad"

Gruß
K-H

[Neutral General]

Zitat:

Gegenfrage : Wo platzierst du den die Datenzugriffskomponenten ?

Entweder auf dem Formular dass die Daten benötigt, oder eben direkt im Quelltext.
Meistens auch lokal in den Methoden selbst.

Bisher mussten viele SQLs z.B. je nach Benutzereingabe dynamisch zusammengestellt werden.
Da bringt eine Query (o.ä.) auf einem Formular nicht sehr viel, da man die SQL eh jedes mal neu
zuweisen muss.

Gefühlt 99% aller Queries werden (auch wenn deren SQL konstant ist) auch nur an einer Stelle im Code benutzt, weil die SQL meistens genau auf ein Problem ausgelegt ist, was genau in dieser Form eben nur 1 mal im Projekt behandelt wird.

Zitat:

Die Tatsache, daß es etwas nur in Delphi gibt und nicht in anderen Sprachen, ist mit Sicherheit kein Nachteil und auf keinen Fall ein Hinweis, etwas nicht zu verwenden.

So war das nicht gemeint und so sollte es auch nicht rüberkommen ;)
Ich kann solche Sichtweisen selbst nicht leiden.
Ich habe nur festgestellt, dass es diese Datenmodule woanders nicht gibt und da ich zusätzlich
keinen großen Nutzen in diesen Dingern sehe hat sich mir die Frage halt gestellt, ob diese Datenmodule überhaupt (noch) eine Existenzberechtigung haben, bzw. ob diese noch genutzt werden.

[mkinzler]

Die Modularisierung nimmt eher zu als ab, deshalb kann deine Frage mit einem klaren Ja beantwortet werden.

[stahli]

Ich finde sie auch praktisch und lege dort z.B. auch gern Timer o.ä. ab.

Sogar in einem Komponentenpackage habe ich ein Datenmodul verwendet um dort Imagelisten oder PopupMenüs komfortabel erstellen zu können. Ich erspare mir da gern mal Tipparbeit, wenn es möglich ist.

[fly_singapore]

Hallo Allerseits,

weil diese Diskussion auf eine ursprüngliche Frage von mir aus ging, wollte ich mir eine Anmerkung dazu nicht verkneifen. Meiner Unwissenheit folgend habe ich auch immer wieder meine DataConnects, Querys und sonstige Components auf die Form gebracht, aber dann aber versucht wiederum alle DB-Operationen in eine extra Unit reinzuschreiben. Die Vorgehensweise mit TComponent gefällt mir, da alle DB-relevanten Operationen zentral und für alle Forms innerhalb der Applikation abgreifbar sind.

[TRomano]

Offensichtlich hast Du noch nicht das Problem gehabt mit sehr komplexen Masken zu arbeiten, wo Du auf viele Datenquellen angewiesen bist. Spätestens da merkst Du dann, dass es unübersichtlich wird. Ich stimme aber genau so einigen anderen Postings zu, dass es einfach konsequenter ist GUI und Daten zu trennen.

[Stevie]

Datenmodule sind die RAD Antwort auf MVC/MVP. Damit beantwortet sich die Frage imo mit einem klaren: ja