Du hast doch auch so schon *drei* Views! Die UI-Elemente fungieren als View egal, *wo* sie im Code stehen. Das hatte ich Dir oben doch schon gesagt - vergiss mal für einen Augenblick Module und Code-Aufteilung! Ein View bleibt ein View - egal, wo er im Code steht!Sophus hat geschrieben:Meinen zweiten Beispiel verstehe ich auch, aber nur solange dies in einem Modul ist. Würde ich das alles auseinander klamüsern, zum Beispiel LisView, Combox und ListView jeweisl ein eigenes Modul (View), dann hätte ich erst einmal drei separate Views. Dann bräuchte ich noch ein Controller und ein Model. Im Model würde ich die Programmlogik packen.
Ein ``QListView`` ist doch auch ein View - und der "steht" ja auch in einem anderen als Deinem eigenen Modul in Beispiel 2!
Die Intention von MVC ist letztlich das Erreichen einer losen Kopplung von Komponenten. Dies leitet sich unmittelbar von den grundlegenden OOP Prinzipien ab, wie z.B. dem "Single Responsability Principle" aus SOLID. (Ich denke mal, damit habe ich Dich bereits öfter konfrontiert) Das alles hat letztlich den Sinn, Software besser entwickeln zu können. Testbarkeit, Parallelisierbarkeit der Entwicklung, leichtere Wartung, Wechsel / Austausch von Komponenten (Open Closed Principle), uvm.
Ob man das selber alles so machen will, bleibt einem selber überlassen. IdR. ist es eine gute Idee, *etablierte* Pattern zu übernehmen - das gilt ja allgemein im Leben
Wie ich schon sagte ist Dein erstes Beispiel gar kein MVC; es fehlt dort schlicht am gemeinsamen Modell. Dein zweites Beispiel zeigt es schon besser: Du hast *ein* Datenmodell, welches in verschiedenen UI-Komponenten dargestellt wird.
Ich würde Dir raten, mal ein simples "Standardmodell" zu nehmen, wie ein Adressbuch, TODO-Liste usw. Diese kannst Du UI-technisch als Liste darstellen, in der lediglich eine *kurze* Information zur Identifikation enthalten ist, wie etwa Vor- und Nachname. Daneben kannst Du dann eine UI-Komponente bestehend aus Labeln und verschiedenen Eingabefeldern basteln, die *alle* Details eines Datensatzes anzeigt. Wählt man in der Liste einen anderen Datensatz, so ändern sich die Details. Editiert man ein Detail (und übernimmt dieses), so ändert sich sofort die Darstellung in der Liste. Schaffe Dir ein Modell, welches die Datensätze nach außen, also für die UI-Komponenten kapselt. Dann integriere dieses Modell in die *beiden* verschiedenen UI-Komponenten. Danach stelle von fixen Demo-Datensätzen auf serialisierte um, die Du aus einer JSON-Datein einliest. Dann stelle das ganze auf eine kleine SQLite-DB um und füge ein ``QtSqlModell`` (sollte so ähnlich heißen!) anstelle des bisherigen ein. Dann baue die Möglichkeit zu filtern und zu sortieren ein (Decorator-Pattern durch Proxy-Klassen). Dabei wirst Du ein Gespühr bekommen, wieso es sinnvoll ist, die Darstellung und Kommunikation bei Aktionen über ein zentrales Modell laufen zu lassen