Sind "Datenmodule" noch aktuell?

[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