qtforum.de

Hi

Ich wollte einmal fragen, wie wir unser Projekt nach dem Model-View-Controller Prinzip in QT am Besten strukturieren können.

In QT ist es ja so, dass es verschiedene Views gibt, wie z.B. TreeView oder TableView. Diese werden von einem Model mit Daten versorgt.

Bei unserem Projekt ist es jetzt so, dass wir erstmal ein MainWindow haben. Dieses beinhaltet die Toolbars und die Menüs und eine Status-Leiste.

In diesem MainWindow sind nun gestapelte Layouts mit einem widgetStack realisiert. Je nachdem, was der Benutzer gerade macht wird die entsprechende Page aufgerufen.

Hier mal exemplarisch skizziert für die Seite "Studenten bearbeiten":


Benutzer -> MainWindow -> StudentsPage


Die StudentsPage enthält eine Liste von Studenten vom Typ TreeView, außerdem noch verschiedene Buttons. Siehe dazu: Bild im Anhang.

Nun ist es so, dass wir diese Liste StudentsView genannt haben. Dazu existiert noch ein StudentsModel, welches das StudentsView mit Daten füllt.

Soweit so gut. Aber jetzt kommt das Problem:

Eigentlich müsste doch die StudentsPage der Controller sein, also ausschließlich die Steuerung übernehmen. Aber dann würde ja die Anzeige von Buttons fehlen, weil wir ja dafür kein View haben, da unser View ja nur die Liste an sich ist. Außerdem werden die Buttons und die Liste in der StudentPage angeordnet.

Aber dann sind ja die Steuerung und die Anzeige der GUI-Elemente nicht sauber voneinander getrennt, weil im Controler Dinge sind, die eigentlich ins View gehören ... ?


Oder habe ich etwas falsch verstanden?

Unsere StudentsView macht eigentlich nicht viel Besonderes, ich weiß nicht ob es überhaupt nötig ist, diese Klasse zu haben, da es prinzipiell nur eine normale TreeView ist, die im Konstruktor ein paar Einstellungen vornimmt.

Wäre es da nicht besser, die StudentsView so wie sie jetzt ist komplett zu löschen und dafür eine neue StudentsView anzulegen, die sich komplett um die Darstellung des GUIs kümmert und in der StudentsPage nur die Steuerung zu haben?

Bin dankbar für jede Antwort.

Gruß

Hiho,


http://de.wikipedia.org/wiki/Model_View_Controller

* Das MVC-Architekturmuster trifft keine Aussage über die Positionierung der Geschäftslogik innerhalb der MVC-Klassen. Diese kann je nach Anwendungsfall besser im Steuerungsmodul (Control) aufgehoben sein oder besser in das Modell verlagert werden (z. B. wenn es mehrere solche Module gibt).

* Auf Grund diverser Probleme bei der Realisierung in objektorientierter Programmierung, bedingt durch die Kapselung werden bei der Implementierung von Dialogen und Fenstern häufig die Steuerung und die Präsentation zusammengefasst. Das entstehende Modell wird Document-View-Modell genannt, in dem das Dokument dem MVC-Modell und die Präsentation (View) der Vereinigung von Steuerung und Präsentation (Control & View) entspricht.

* Das Zusammenfassen von Steuerung und Präsentation ist problematisch, wenn zu einem Modell mehrere Präsentationen angezeigt werden, wie zum Beispiel die gleichzeitige Darstellung einer Tabelle als Text und als Kreisdiagramm. Hier sollte gewährleistet sein, dass eine Änderung des Modells sich anschließend in allen Präsentationen widerspiegelt. Der bessere Weg ist hier, dass die Steuerung nur das Modell ändert und dieses dann automatisch - gegebenenfalls erst nach einer Massenbearbeitung - alle Präsentationen nachführt, was am besten durch eine Trennung von Steuerung und Präsentation realisiert werden kann. In objektorientierten Umgebungen und in verteilten Netzen, kann die Steuerung gar nicht ohne weiteres ermitteln, wieviele und welche Präsentationen eines Modells gerade existieren und nachgeführt werden müssen.

Also so wie ich das sehe machst du dir zu viele Gedanken, dein Ansatz klingt für mich ok. Und ehrlich gesagt, bei so einfach strukturieren Daten hätte ich nicht mal ein Model selber gebaut, sondern vielleicht einfach ein QSqlQueryModel genommen (falls die Daten aus einer DB kommen).

Ich arbeite viel mit eigenen Models und bin für mich zu dem Schluß gekommen, dass der Entwurf/Umsetzung sich erst mal rechnen muss. Viele Dinge sind mit einem QTreeWidget einfach schneller abgehandelt, wenn man weiß, dass der Code an dieser Stelle nicht mehr viel erweitert werden muss in der Zukunft.

Wo ich Models absolut genial finde sind ist, wenn jedes Item in einem Model sehr viele Stati und Informationen annehmen kann und auch visualisieren muss. Kleines Beispiel: Eine Kamera an einem DVR. Die Kamera hat eine ID, diverse Zusatzinformationen und Freischaltungen für bestimmte Benutzeraktionen und ist mit einem Recorder (aus einem weiteren Model) gekoppelt. Die Kamera kann ausfallen, ein schlechtes Signal haben, einen Bewegungsalarm auslösen (+ zig weitere Alarmtypen), die Kamera kann vom Recorder aufgezeichnet werden oder auch gerade nicht usw usw usw. Wenn man diese Daten in einem Model abbildet, hat man auf einfache weise die Möglichkeit die diversen Stati und Informationen mittels Icons, Tooltips, Beschriftungen oder z.B. Bold-Fonts bzw Farben zu visualisieren. Wenn man dazu noch den View ableitet kann man anhand der Funktionsfreischaltungen einer Kamera das Kontextmenü der Kamera zusammenstricken und nur freigegebene Aktionen anbieten.


Also mein persönliches Fazit: MVC ist genial wenn es für jedes Item viele darzustellende Informationen gibt, bei kleinen Datenmodellen ist es aber häufig sinnvoller fertige Models zu verwenden oder die paar Zeilen zum Füllen eines TreeWidgets einfach selbst zu schreiben.

EDIT: DesignPatterns sind keine Vorschriften nach dem Motto "So MUSST du es machen". Es sind Hilfestellungen (best practice) erfahrener Softwarearchitekten. In jedem Buch zu dem Thema kann man lesen, dass man nicht zwanghaft Patterns einsetzen sollte, sondern sich immer wieder darüber Gedanken machen soll wann und in welchem Umfang man Patterns einsetzt. Patterns sind keine Gebote die man einhalten muss, oft machen eigene/andere Strukturen mehr Sinn bzw sind in genau dieser Situation einfach besser und einfacher umzusetzen.


Ciao,
Sephral

Vielen Dank, dein Beitrag war sehr aufschlussreich.

Ich mache mir nur so viele Gedanken, weil es sich um ein Projekt für das Studium (Fach Software Engineering) handelt und es nicht nur darauf ankommt, dass alles funktioniert, sondern auch, dass es eine möglichst gute Architektur hat.