Code Design

[manfred_h]

Hallo zusammen

habe hier eine hoffentlich nicht zu triviale Frage:

Bei einer DB-Anwedung die ich als SDI erstellt habe befinden sich 10x PageControl im Haubtfenster
plus 3 "Child" PageControl.
Ist das "Designmäig" ok das der Code für alle Tabs in dem selben Form landet?
Würdet ihr das irgendwie auslagern? Jeder Tab lädt den code von 123.pas oder so? Geht das? :oops:

Bin für Eure Ideen dankbar.

Manfred

[Sebastian R.]

Möglich ist das schon, und "design-mäßig" musst du das selbst entscheiden. Wir sehen nachher nur dein Programm nicht deine tausend Seiten Quelltext! ;)

Wenn du selbst damit klarkommst, sprich wenn dich das nicht aus dem Konzept wirft, dann kanns du das ruhig machen. Kein Problem! ;)

MfG, Sebastian R.

[manfred_h]

Wow diese Anwort kam aber echt schnellllll... :thumb:

besten dank für deine Antwort.

Manfred

[Phoenix]

Das ist ungeschickt.

Normalerweise sollte man immer versuchen, Code und Oberfläche voneinander zu trennen.

Stell Dir mal vor, Du musst irgendwann in ein, zwei Jahren deine Anwendung von SDI auf Web umstellen und musst dann den Code von Deinem einem Form auf zig Webseiten verteilen. Mit Code in einem einzigen Form würde ich da hergehen, das komplett wegwerfen und neu anfangen... das geht in der Regel schneller.

Wenn Du Deinen Code aufteilst und in verschiedene Klassen packst, die jeweils in einer eigenen Datei liegen kannst Du das wiederverwenden. Zu jeder Arbeits-Klasse (mit der Programmlogik) gehört dann noch eine Oberflächen-Klasse, die nur den In- und Output vom Formular in die Arbeitsklasse und zurück übernimmt - mit wohldefinierten Schnittstellen dazwischen. So kannst Du hinterher nämlich einfach hergehen und auch mal die Tabseite in ein eigenes Form (oder auf eine Webseite) legen und die Arbeitsklasse hintendran brauchst Du nicht mal ansatzweise anzufassen.

[manfred_h]

Zitat:

Zitat von Phoenix

Wenn Du Deinen Code aufteilst und in verschiedene Klassen packst, die jeweils in einer eigenen Datei liegen kannst Du das wiederverwenden. Zu jeder Arbeits-Klasse (mit der Programmlogik) gehört dann noch eine Oberflächen-Klasse, die nur den In- und Output vom Formular in die Arbeitsklasse und zurück übernimmt - mit wohldefinierten Schnittstellen dazwischen. So kannst Du hinterher nämlich einfach hergehen und auch mal die Tabseite in ein eigenes Form (oder auf eine Webseite) legen und die Arbeitsklasse hintendran brauchst Du nicht mal ansatzweise anzufassen.

Hallo Phoenix

das hört sich interessant an. Kennst Du ein Tutorial indem das ein wenig erleutet wird?
Ich hab mir vorhin einmal die Delphidemo (Marine Adventures) angeschaut.
Dis ist mit einem Master Forumlar und ein paar Childs gelöst.

Das sieht auch mit dem Source logisch aus.
Was ich jetzt nicht weiss ist wie kann ich in >einem< Formular den Code in verschiedene Dateien Auslagern?

Manfred

[Phoenix]

Hi.

Als ein Tutorial gibts da meines Wissens nach nicht. Aber eine Anwendung sollte eben in mehreren Schichten arbeiten:

Buisiness-Logik <--> Abstraktionsschicht <--> Oberfläche

Und das Auslagern von Code... ich würde das eben nicht klassisch auslagern (wie in einer Include-Datei) sondern das ganz normal lösen: Du machst einfach eine neue Datei mit den entsprechenden Klassen drin und bindest die in der Uses-Klausel ein. That's it.

[manfred_h]

Danke Sebastian R.

für deine Tipps und Zeit :love:

mit freundlichen Grüssen :cheers:
Manfred

[sir-archimedes]

Dazu hätte ich auch noch eine Frage/etwas zu sagen: Viele (kommerzielle) Anwendungen sind ja - ganz böse ausgedrückt - nicht viel mehr, als "Datenbankfrontends". Hier verwendet man in der Regel die datensensitiven Controls, die Delphi mitbringt, Datenbankverbindungsobjekte und verknüpft das miteinander. Häufig ist hier so viel Logik gar nicht enthalten. Da fällt es meiner Meinung nach schwer, wirklich sauber die Schichten zu trennen. Zumindest mit Delphi.

Oder wie würde das wirklich sauber aussehen? Ich bräuchte quasi eine Schnittstelle, die mir die Objekte transparent in "Queryzeilen" umwandelt und zurück - also mehr oder weniger so etwas, wie ein "Objekt-Persistenz-Framework".

[Phoenix]

Jo, da gibt es ja z.B. ECO. Viele Firmen haben da schon Eigenentwicklungen oder man greift zu kommerziellen Frameworks die soetwas für Dich machen - die kosten dann aber auch ein paar Tausend Euro ;-)

Wenn es wirklich 'nur' um ein Frontend geht brauchst Du die Aufteilung nicht.
In anderen Fällenwürde ich für den 'kleinen Hausgebrauch' die datensensitive Logik in eine von TTable abgeleitete Klasse packen und nötige Transformationen hier ablegen. Diese TTable hängst Du dann an Dein Form und lässt die arbeiten. Geht schnell und auch hier hast Du Daten- von Oberfläche getrennt.