Trennung Gui-Logik, wie genau umsetzen z.B. beim Laden von Dateien?
-
Hi,
Ich mache gerade meinen ersten Versuche mit Gui-Programmen und habe eine Frage bzgl. der oft geforderten Trennung von Gui und Programmlogik. Also mir ist klar, dass die Gui halt nur Gui Sachen machen soll. Also bspw. Objekte entgegennehmen und deren Inhalt anzeigen.
Konkret beschäftigt mich aber folgende Frage: Wenn ich in meinem Programm Dateien von der Festplatte mittels Gui einlese (mittels File-Choose Dialogs), speichert man die geladenen Objekte dann auch in gui-Objekten? Also wenn z.B. im Hauptfenster das File-Chooser Event getriggert wird und der User wählt daraufhin eine Datei bzw. einen Dateinamen aus, erzeugt man dann ein entsprechendes Objekt (z.B. ein Image-Object) direkt und speichert es als Member des Hauptfensters? Oder sollte man den gewählten Dateinamen irgendwie weiter durchreichen (wie macht man sowas in Event getriggerten Systemen)?
Kleine Frage, die mir gerade aber Kopfzerbrechen bereitet.
Meiner
-
Das geht irgendwie am Kern der Sache völlig vorbei. Die Trennung hast du schon z.B. in Form des Image Objekts. Würdest du jetzt in der GUI, z.B. direkt in dem File Chooser Event anfangen, die Bildaten zu laden und zu interpretieren, z.B. einen JPEG Decoder, wär das ganz schlecht. So ist es aber schon gekapselt (sogar mehrschichtig, die Image Klasse kümmert sich um die allgeinen Aufgaben, das Laden der verschiedenen Formate ist auf weitere Klassen aufgeteilt). Was du fragst ist ziemlich unwichtig.
-
Im Prinzip war das ja auch mein Gedanke. Nur teilweise habe ich z.B. folgende Aussagen aufgeschnappt: "Man soll seine Daten nicht im gui-Objekten speichern" und wusste nicht wie ich das in meinem Kontext einzuordnen hatte, denn aus meiner Anfänger-Sicht (was genau das Problem ist und deshalb war die Frage nicht "unwichtig" für mich), hab ich den Trennungsgedanken bereits erfüllt.
-
"Daten" würde ich etwas allgemeiner verstehen. Du solltest Logikklassen haben, die die Funktionalität kapseln, die kannst du dann aber in der GUI halten (wenn sich das anbietet). Sagen wir, du hast ein "Projekt", zu dem eine Liste von Dateien gehört, Namen, Einstellungen usw. Dann sollte man sowas auch in einer Project Klasse oder so kapseln und nicht in deiner GUI lauter Felder dafür anlegen und dann irgendwie pflegen. Ist aber kein Problem, wenn die GUI die Project Klasse hält und die z.B. von der Festplatte laden kann.
-
Meiner schrieb:
Im Prinzip war das ja auch mein Gedanke. Nur teilweise habe ich z.B. folgende Aussagen aufgeschnappt: "Man soll seine Daten nicht im gui-Objekten speichern" und wusste nicht wie ich das in meinem Kontext einzuordnen hatte, denn aus meiner Anfänger-Sicht (was genau das Problem ist und deshalb war die Frage nicht "unwichtig" für mich), hab ich den Trennungsgedanken bereits erfüllt.
Geht es bei der Trennung nicht eher um das, wo ist die Logik des Prozesses und was darf/soll die Presentation (GUI) davon übernehmen?
Denken wir mal ein bisschen weiter. In jedem Betrieb gibt es Geschäftsprozesse, die in der IT abgebildet werden. Was gehört zum Prozess, was gehört ins GUI und was gehört etwa in die Datenbank?
Hier gibt es viele Meinungen. Ich jedenfalls denke hier sehr konservativ (schon aus Kostengründen). Die Businesslogik (Prozess, Anwendungsprogramm) sollte ganz klar getrennt sein von der Presentation (im GUI sollten formale Prüfungen erfolgen
wie etwa numerisch, Datumsformat etc. und sonst nichts) und NULL Logik in der Datenbank (keine stored Procedures, Trigger usw.), ausser natürlich die Kontrolltechnik, wie etwa RI bei einer relationalen DB.
Wer seine Prozesse so organisiert, macht sich das Leben in der IT einfacher..