Fragen zum MVC Pattern
-
Hi,
Bisher habe ich meine grafischen Oberflächen maximal in 2 Klassen, Logik und GUI erstellt, aber das erschien mir relativ unpraktisch, vor allem zum testen, daher habe ich mir das MVC Pattern mal genauer angeschaut und da treten bei mir einige Fragen auf.
1. Das ist doch ein Designpattern, wieso listen die Wikipediaartikel Implementationen in GUI Frameworks auf, wenn Design Patterns doch unabhängig von der Sprache und den Libs sein sollen? Ich nutze wxWidgets, spricht aber irgendetwas dagegen den Controller in Form von Callbacks(Mit Boost.Function) beim View einzutragen und den View als Observer beim Model?
2. Wie viele Modelklassen sollen eigentlich existieren? Eine für alles, eine für jeden logischen Zusammenhang, oder ganz anders?
3. Soll das Model nur die für die Aufgabe relevanten Daten halten, oder alle?(Also z.B. auch die Position der einzelnen Controls, wenn diese für die Aufgabe irrelevant ist)
4. Was kriegt der Besitzer des Controls? View, Model, Controller, oder alles?
Was darf er kriegen, also soll es in der Klasse, die der Besitzer des Steuerelementes kriegt getter für den Rest geben?
-
JustAnotherNoob schrieb:
Bisher habe ich meine grafischen Oberflächen maximal in 2 Klassen, Logik und GUI erstellt,
Das ist oft sogar sinnvoller als MVC und nennt sich Document/View.
1. Das ist doch ein Designpattern, wieso listen die Wikipediaartikel Implementationen in GUI Frameworks auf, wenn Design Patterns doch unabhängig von der Sprache und den Libs sein sollen? Ich nutze wxWidgets, spricht aber irgendetwas dagegen den Controller in Form von Callbacks(Mit Boost.Function) beim View einzutragen und den View als Observer beim Model?
Eine Frage die mit "Warum" und "Wikipedia" beginnt ist sinnlos :p
Es spricht nichts dagegen. MVC ist wie du gesagt hast ein Design Pattern und unabhaengig der verwendeten Technologie.2. Wie viele Modelklassen sollen eigentlich existieren? Eine für alles, eine für jeden logischen Zusammenhang, oder ganz anders?
idR eine pro Modul.
aber was ein modul ist, ist tricky zu definieren
Ein Fenster zum Beispiel kann ein Modul darstellen, aber uU hast du fuer bestimmte Einstellungen eigene Fenster um diese zu taetigen, so wuerden diese ebenfalls noch in das Model fallen.
Ein neues Fenster koennte aber nur ein anderes View auf ein bestehendes Model sein...
Eine Trennung ist deshalb nicht leicht zu definieren.
3. Soll das Model nur die für die Aufgabe relevanten Daten halten, oder alle?(Also z.B. auch die Position der einzelnen Controls, wenn diese für die Aufgabe irrelevant ist)
Ist das eine Akademische Frage oder eine Praktische?
Akademisch: nur die notwendigen Daten.
Praktisch: alle noetigen.Oft ist es technisch umstaendlich oder performance technisch problematisch wenn die einzelnen Elemente (Model, View, COntroller) zuviele anfragen untereinander stellen muessen um an die daten zu kommen.
Im Prinzip haelt meistens das Model aber die meisten Daten und der Controller die wenigsten. Aber das ist nicht in Stein gemeisselt...
4. Was kriegt der Besitzer des Controls? View, Model, Controller, oder alles?
Was darf er kriegen, also soll es in der Klasse, die der Besitzer des Steuerelementes kriegt getter für den Rest geben?Was ist ein Control bei dir? Ein Steuerelement? Das waere Teil des Views. Und das View hat natuerlich eine Referenz auf das Model. Waehrend das View observer des Controllers ist.
Aber ich denke diese Frage solltest du genauer stellen, da ich sie nicht ganz verstanden habe.
-
Danke so weit.
Ich meinte mit Control das ganze Fenster(also ein selbstentwickeltes Steuerelement in dem Fall)