Wohin mit den Nicht-Visuellen Komponenten?

[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...

[Ralf Kaiser]

Zitat von 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.

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 von mkinzler:

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 von Alfi001:

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.

[Neumann]

Ich würde die nichtvisuellen Komonenten auch möglichst in Datamodule oder auch auf normale Forms, die nie angezeigt werden auslagern.

Wenn es nicht geht (z.B. Mainmenu hab ich noch nicht versucht) dann kann man GExperts installieren, mit dem man diese Komponenten bei Bedarf sichtbar/unsichtbar machen kann.

[mkinzler]

Ein Menü ist ja auch irgendwie visuell

[Stevie]

Zitat von Alfi001:

Zitat von 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.

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)

Ich sagte ActionList, und nicht die Events davon... Angenommen, du hast nen MenuItem im MainMenu, eins in nem PopupMenu und noch nen ToolButton. An alle 3 kommt die gleiche Action. Dann kommt das Event ins DataModule (oder sonstwo hin, aber nicht ins Form!) aber die ActionList kann locker aufm Form bleiben.

[Jazzman_Marburg]

Merci!

Gruß
Jazzman

[Luckie]

Zitat von 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.

What you can do at designtime, don't do at runtime. Daran halte ich mich auch in der Regel, weil überflüssiger Code dann nicht im Quelltext auftaucht. Und wer Eigenschaften in den Komponenten verstellen kann, kann dies auch im Quelltext. Das kann also keine Begründung sein. Aber gibt es denn so viele nicht-visuelle Komponenten, dass man sich sein ganzen Formular zu pflastern kann? Ich schiebe sie meist irgendwo in die Ecke, wo sie nicht stören.