![]() |
Wohin mit den Nicht-Visuellen Komponenten?
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 |
AW: Wohin mit den Nicht-Visuellen Komponenten?
Lies mal die Hilfe zu
![]() |
AW: Wohin mit den Nicht-Visuellen Komponenten?
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??? |
AW: Wohin mit den Nicht-Visuellen Komponenten?
*Hihi* schneller :zwinker:
|
AW: Wohin mit den Nicht-Visuellen Komponenten?
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.
|
AW: Wohin mit den Nicht-Visuellen Komponenten?
Dann muss man aber auch alle Einstellungen im Code setzen
|
AW: Wohin mit den Nicht-Visuellen Komponenten?
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... |
AW: Wohin mit den Nicht-Visuellen Komponenten?
Merci! :wink:
Gruß Jazzman |
AW: Wohin mit den Nicht-Visuellen Komponenten?
Zitat:
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) |
AW: Wohin mit den Nicht-Visuellen Komponenten?
Zitat:
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:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:19 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz