Qt GUI und Logik trennen



  • Hey Leute,
    nach einigem hin und her bin ich jetzt wieder bei Qt angekommen 😃 Ich hab mich damals an Qt rangemacht, jedoch gefiel mir es irgendwie einfach nicht, hab dann erst mal mit weiter mit reinem C++ beschäftigt. Hab mich dann irgendwann mal an der MFC versucht, das war jedoch gar net mein Ding, hab dann mal ein bisschen was mit der WIN-API gemacht um auch ein bisschen Hintergrundwissen zu erlangen, jedoch ist mir das mit der WIN-API auf Dauer zu viel Arbeit und Stress 😉

    Also hab ich mich jetzt nochmal an Qt rangewagt und komm auch eigentlich wieder ganz gut zu Recht, mittlerweile gefällts mir sogar sehr, die Dokumentation ist halt auch echt einfach spitze, sodass ich in Zukunft bei GUI-Sachen, wenn mir also mal die Konsole nicht reicht, und anderen Sachen die die STL oder Boost nicht haben auf Qt setzte.

    Jetzt wollt ich mal Fragen wie ihr das vom Design her handhabt, sodass die GUI und die eigentliche Programmlogik getrennt sind und es bei größeren Projekten nicht ein totales Misch-Masch wird und im Chaos endet 😃

    Würde mich über Tipps, Beispiele und Vorgehensweisen sehr freuen.

    Lg freeG



  • Es ist bestimmt nicht einfach darauf eine Antwort zu geben aber auch mich würde interessieren wie man GUI und Logik sauber trennen kann. Ich habe mit Qt angefangen bin jetzt aber im Moment bei FLTK gelandet und werde aber Qt noch später wieder aufgreifen. Für meine Testprogramme reicht mir FLTK locker aus und ich kann viel lernen. Es wäre natürlich toll auch mal zu Erfahren wie ich eine Anwendung so entwickle das ich später relativ leicht auf Qt wechseln kann.

    Gruß Blue-Tec


  • Mod

    Also, so mache ich es i.d.R. wenn ich trenne:

    Backend ohne Qt kommt in jeweils eigene DLLs (das hat was mit der LGPL zu tun).
    Frontend dann in Qt, und dazwischen je nach Aufwand halt ein Qt Model/View (so macht man es in Qt "korrekt"),
    oder ich frickel bei kleineren Sachen das auch mal gerne selber hin:

    MyDialog::MyDialog(shared_ptr<Data> data):data(data){}//mit data wird nun der Dialog initialisiert, Textfelder belegt usw. usf.
    MyDialog::TransferData()//hier übertrage ich die Daten in die jeweilige datenquelle
    


  • Also ich persönlich versuche den "Programmkern" immer völlig unabhängig von einer GUI zu halten. D.h. ich verwende die STL und BOOST. Für die GUI nehme ich normalerweise wxWidgets.



  • Wie immer: kommt darauf an.

    Willst du irgendwann Qt völlig loswerden oder hast du kein Problem damit Qt-Klassen weiter zu benutzen (weil Qt ja inzwischen eine Menge mehr bietet als nur reine GUI) aber willst nur die GUI austauschen?

    Letztendlich musst du halt aufpassen, dass du keinerlei Verarbeitung in deinen GUI-Klassen oder widgets durchführst. Auch musst du aufpassen, dass du keine Signal-Slot Verbindungen zwischen Gui-Schicht und deiner Business-Logik herstellst (wenn du nur die GUI austauschen können willst aber Qt-Klassen weiterhin benutzen willst kannst du natürlich innerhalb der business-logik signals-slots 'missbrauchen' soviel du willst.)
    Generell macht man so eine Trennung über eine Zwischenschicht die die GUI-spezifischen Signale Verarbeitet und für den Kern deiner Anwendung übersetzt (Stichwort: MVC (model-view-controller pattern) oder MVVM (model-view-viewmodel))

    Im letzten Projekt hatten wir Model-View-Controller (mit MFC und nicht Qt - aber das ist ja relativ egal für die Diskussion hier). Es war bereits angedacht das ganze auf Qt umzustellen. dafür muss man halt die GUI neu aufsetzten und den Controller von message maps auf signals-slots ändern - aber die algorithmik/datenbankanbindung/etc. bleiben völlig unberührt.



  • Danke für die Antworten, hab mir das mit dem MVC mal angeschaut und soweit versteh ichs auch bisher. Also ich hab jetzt bei nem kleine Projekt von mir schonmal Model und View implementiert mit Hilfe vom ObserverPattern. Mit fehlt jettz noch der Controller. Meine Frage ist aber nun, mit was für nem Design Pattern "interagiert" der Controller mit der View und dem Model.

    Löst man das auch mit Observer Pattern?
    Oder sollte ich in meiner GUI-Klasse sprich View Signale auslösen die dann mit Funktionen vom Controller connectet sind? Und diese Funktionen ändern dann das Model? Sprich im Controller brauch ich nur einen Verweis auf mein Model?

    Schonmal vielen Dank.

    Lg freeG


Anmelden zum Antworten