Wohin mit den Nicht-Visuellen Komponenten?

[Jazzman_Marburg]

Hallo Kollegen,
wohin packt ihr eure Nicht-Visuellen Komponeneten im Form-Designer?
Ich habe davon mittlerweile ein gutes Dutzend auf der Form liegen, und ziehe sie bei jeder Gelegenheit zur Seite, weil sie eigentlich überall nur stören (andere Dinge verdecken, die man gerade bearbeitet).
Haben die erfahrenen Delphianer einen Workaround?

Fragt sich und grüßt
Jazzman

[DeddyH]

Lies mal die Hilfe zu TDataModule.

[Ralf Kaiser]

Du könntest die Komponenten einfach auf ein Datenmodul packen. Es heisst zwar Datenmodul aber muss nicht nur Datenkomponenten enthalten!

EDIT: Grrrr. Hat der rote Kasten Urlaub???

[DeddyH]

*Hihi* schneller :zwinker:

[schlecki]

oder selbst im Quellcode erzeugen - das hat dann sogar den Vorteil, dass diese nicht als Komponenten installiert werden müssen; dadurch kann man die Libs dann leichter projektweise updaten.

[mkinzler]

Dann muss man aber auch alle Einstellungen im Code setzen

[Stevie]

Ein ganz klares: Kommt drauf an. Komponenten, die primär für GUI Funktionalitäten zuständig sind (dazu würde ich z.B. eine ActionList zählen) dann gehören sie für mich auf die Form. Hast du allerdings Dinge, wie DBConnection, Datasets (über Datasources müsst ich nochmal nachdenken, wo die für mich hingehören) kann man die in ein DataModule packen. Allein um Wiederverwendbarkeit und Trennung von GUI und BL zu gewährleisten.

P.S. Ich hasse das Erzeugen von Komponenten im Code, wenn man sie auch im Designer platzieren könnte...

[Jazzman_Marburg]

Merci! :wink:

Gruß
Jazzman

[Ralf Kaiser]

Zitat:

Zitat von Stevie (Beitrag 1105813)

Ein ganz klares: Kommt drauf an. Komponenten, die primär für GUI Funktionalitäten zuständig sind (dazu würde ich z.B. eine ActionList zählen) dann gehören sie für mich auf die Form.

Das sehe ich ein wenig anders.

Also gerade Actionlisten enthalten, zumindest meiner Meinung nach, doch grosse Teile des Business-Logik. Fügt man diese in ein Datenmodul ein so hat man die Logik in diesem Modul "gesammelt" und von der GUI, also dem Formular, getrennt.

(wobei z.B. OnUpdate-Methoden eventuell da eine "Grauzone" darstellen)

[jaenicke]

Zitat:

Zitat von mkinzler (Beitrag 1105809)

Dann muss man aber auch alle Einstellungen im Code setzen

Richtig, und das ist auch gut so. Sonst wundert man sich plötzlich warum irgendetwas nicht mehr geht, dabei hat nur jemand aus Versehen eine Eigenschaft umgestellt.

Bei größeren Projekten wird das allerdings auch unübersichtlich, wenn man das nicht gut kapselt. Deshalb ist es nicht so eindeutig was wo sinnvoll ist...

Klar ist jedenfalls eins:
Um die Oberflächen an sich von deren Logik sowie der Businesslogik und den Daten zu trennen, macht es Sinn alles auszulagern was nur geht. Wenn man das über mehrere Schichten macht, kann man leicht die Oberfläche auswechseln ohne deren Logik mit auswechseln zu müssen.

// EDIT:

Zitat:

Zitat von Alfi001 (Beitrag 1105815)

Also gerade Actionlisten enthalten, zumindest meiner Meinung nach, doch grosse Teile des Business-Logik.

Naja, eigentlich ja nicht direkt. Die entsprechenden Handler geben das ja nur (etwas aufbereitet) an die eigentliche Oberflächenbehandlung weiter.