MVC in komplexen Programmen

[Hoagie]

Hallo,

ich habe ein kleines Verständnisproblem mit dem MVC-Pattern. In den vielen Tutorials, die ich mir bisher angeschaut hatte, war meist nur von einem (!) Model, View und Controller im Programm die Rede. Wie sieht es bei einem komplexeren Programmaufbau aus? Behält man tatsächlich für sämtliche Aktionen einen Controller und ein Model bei?

Um mein Problem etwas zu verdeutlichen vielleicht noch ein Anwendungsbeispiel.

Ich habe zum Beispiel ein Programm geschrieben, das zu verschiedenen Algorithmen eine passende Visualisierung grafisch darstellen soll. Es handelt sich dabei um Such- und Sortierverfahren. Im eigentlichen Programm geschieht nun das eigentliche Vorgehen des jeweiligen Algorithmus. Sprich es wird z.B. ein Array sortiert.
In der GUI bzw. im View soll das ganze nun z.B. durch verschieden hohe Balken verdeutlicht werden. Also muss die grafische Oberfläche die Änderungen im Array (Model) beobachten (Stichwort Observer-Pattern) und dann z.B. jeweils eine Animation pro Swap abspielen.

So weit so gut. Aber jetzt habe ich noch den Teil des Programms, der für Suchverfahren zuständig ist. Das ganze spielt sich natürlich mit anderen internen Daten ab und die Operationen sind anders. Allerdings steckt das ganze in der selben GUI wie die Sortierverfahren (Man kann mit Tabs zwischen diesen Modi schalten). Es steckt dahinter zwar eine andere Visualisierung, aber es befindet sich trotzdem in dem View-Teil.

Zum Verdeutlichen ein kleines Klassenmodell (Ziemlich vereinfachte Version).

/* View */
MainView.class // Erstellt die Gui mit zwei "Unterpunkten" (Sortieren, Suchen)
SortPanel.class // Enthält Visualisierungen zu den Sortieralgorithmen
SearchPanel.class // Das Äquivalent für Suchalgorithmen
BarCanvas.class // Visualisierung für Sortieralgorithmen (im SortPanel)
[...]

Aus all diesen Klassen setzt sich die gesamte GUI zusammen.

/* Core */
UiController.class // Allgemeine Aufgaben wie z.B. das Öffnen von neuen Fenstern

Und genau hier liegt der Knackpunkt. Nach meinen Vorstellungen müsste es nun zu jeder "Teil-GUI" einen speziellen Controller und ein Model geben. Das gesamte würde dann beispielsweise so aussehen:

SortController.class // Sämtliche Methoden zum Steuern der Sortierprozesse.
SortModel.class // Enthält z.B. ein Array, welches mithilfe des Controllers und somit auf Knopfdruck in der GUI sortiert wird.
SearchController.class // ...
SearchModel.class // ...

Also muss man nach diesem Model mit mehreren Observern arbeiten (Einen pro "Teil-GUI"), wenn ich das richtig interpretiere. Ist dies denn ein eleganter Weg mein Vorhaben umzusetzen? Ich hoffe wirklich, dass ihr mir bei diesem Problem helfen könnt. ;-)

Gruß,
Hoagie

 

[stevieboy]

Das MVC-Pattern beschreibt nur den Programmaufbau in Sachen Aufgabenteilung. Es ist imho durchaus legitim, mehrere verwaltende Klassen zu nutzen,sofern diese abgrenzbare Aufgaben haben.

In Deinem Fall sehe ich überhaupt kein Problem darin, mehrere Komponteten pro Schicht zu haben, denn schließlich könnten diese auch völlig getrennt in 2 Programmen gehandhabt werden.

Wichtig ist eigentlich nur, dass Du die "Kommunikationswegen" einhältst: View <-> Controller <-> Model, somit gewährst Du Dir maximale Modularisierbarkeit, also auch minimale Abhängigkeit.


Zusatz:

In größeren Projekten wäre es zusätzlich anzuraten, die einzelnen Teile jeweils ein Interface implementieren zu lassen und NUR diese Interfaces zum Zugriff auf die jeweiligen anderen Klassen zu haben:

So könnte es bei Dir halt ein SortModelInterface geben,welches dem Controller bekannt gemacht wird. Jede Klasse, die Sortierdaten hält würde das Interface implentieren und der Controller kann über die im Interface definierten Methoden darauf zugreifen. Somit kann man die komplette Implementierung eines Models von den anderen Komponenten abkoppeln.

Da diese Art zu programmieren zwar Vorteile hat, aber aufwendiger ist, gerade wenn man das Inteface "on the fly" schreibt und daher dauernd Anpassungen vornehmen muss, lohnt es sich erst ab einer bestimmten Größe bzw. wenn eine längere Nutzung inkl. Pflege und Weiterentwicklung geplant ist.

 

[SnooP]

Nicht nur legitim - bei großen Programmen eher die Regel. MVC sollte da als Schichtenmodell verstanden werden. In Webanwendungen hat man typischerweise für jede View (JSP-Seite) einen Controller, der auf jeweils unterschiedliche Modellklassen zugreift - beispiel: Stammdatenpflege mit Personen und Adressen in zwei Views: verweisen jeweils auf einen Controller, der auf eine Person und eine Adresse-Klasse zugreift... dia Datenzugriffsschicht ist dabei noch zwischen Controller und Modell geschaltet über zumeist sog. DAOs.

zum praktischen Vorgehen bei dir... - Observer bzw. Listener. Hab das Problem aber noch nicht in Gänze verstanden

 

[Guest]

In größeren Projekten wäre es zusätzlich anzuraten, die einzelnen Teile jeweils ein Interface implementieren zu lassen und NUR diese Interfaces zum Zugriff auf die jeweiligen anderen Klassen zu haben.

Hallo, kann jemand dazu ein kleines Beispiel posten?
Danke schonmal.

 

[stevieboy]

In größeren Projekten wäre es zusätzlich anzuraten, die einzelnen Teile jeweils ein Interface implementieren zu lassen und NUR diese Interfaces zum Zugriff auf die jeweiligen anderen Klassen zu haben.

Hallo, kann jemand dazu ein kleines Beispiel posten?
Danke schonmal.

Hier ist quasi der große Bruder dieses Threads

Klick

Wenn Du Dir diese Beispiele angesehen hast und dazu Fragen hast, dann stelle Sie dort bitte einfach rein.

HTH,

Stevie