Best Practice Frage zur Umsetzung MVC

[White_Fox]

Hallo liebe Leute

Ich hatte eine View, ein Model und einen Controller für mein Programm und war fast soweit, eine erste lauffähige Minimalversion zu haben. Dann hab ich festgestellt, daß ich mich heillos im Code verzettelt habe. Also vieles gelöscht und nochmal von vorne begonnen und das Ganze vorher mal grafisch hingemalt.

Jetzt ist meine Frage: Geht das so, kann man das so machen oder wird das Mist? Da ich vom Programmieren ja eigentlich keinerlei Ahnung habe wollte ich mal eure Meinung dazu hören bevor ich wieder einen dritten Anlauf unternehmen muß bis es mir gefällt. Auch von UML hab ich keinerlei Ahnung (wie stellt man sowas eigentlich richtig dar?), aber vielleicht gibt das Bild eine Idee davon wie ich mir das gedacht habe:



Ich fange mal mit der View an: Ich plane, hier zwei Interfaces zu implementieren um die für Controller und Model interessanten Methoden getrennt darstellen zu können. Die View übergibt dem Controller ein Command-Objekt (nicht dargestellt), das den vom Benutzer ausgewählten Befehl darstellt. Der Controller führt dann das Command-Objekt auf dem Model (dafür das Commandable-Interface) aus, später soll der Controller die Command-Objekte speichern, um Befehle wieder rückgängig zu machen.

Model<>View ist ein schnödes Beobachtermuster: Das Model triggert die View mit einer Modelchange-Enumeration, die View holt sich daraufhin beim Model die benötigten Daten ab.

Eine ähnliche Beziehnung gibt es nochmal zwischen View<>Controller: Hier teilt der Controller der View mit, ob z.B. ein Befehl rückgängig gemacht werden kann oder ob nach einer Rückgängig-Orgie wieder vorgespult werden kann.

Was sagt ihr dazu? Was würdet ihr anders machen? Ich habe einerseits noch sehr viele Ideen, die ich gerne implementieren will, andererseits will ich wenigstens einen Teil des Programms endlich mal benutzen können. Daher will ich das Ganze so halten, das Erweiterungen möglichst ohne größere Schmerzen eingebaut werden können.

 

[mihe7]

View, Model und Controller sind IMO nur Rollen, die von Objekten gespielt werden. Dabei gibt es nicht "die View-Klasse", genauso wenig wie es für eine View nur "das Model" und "den Controller" gibt. Hinzu kommt, dass MVC in gefühlten 1000 Varianten existiert und jeder etwas anderes darunter versteht.

Ein JPanel beispielsweise wird nicht dadurch zur View, indem es ein Interface implementiert. Es kann mehrere "Views" enthalten, die ihrerseits mehrere Models/Controller besitzen können. In der "Gesamtschau" lässt sich das JPanel als "View" betrachten, die Gesamtheit aller Models als "Model" usw.

Dann gilt zu berücksichtigen, dass Models auf unterschiedlichen Ebenen existieren. Ist es ein Model, das man der Präsentationsschicht zuordnet, also die UI-Logik kapselt? Oder ist es ein Model, das (den Zugriff auf) die Anwendungslogik darstellt?

Es ist also äußerst schwierig bis unmöglich, anhand von "View", "Controller" und "Model" irgendwelche Einschätzungen vorzunehmen.

 

[White_Fox]

Sowas hab ich befürchtet...

Soll ich das also einfach mal so machen?

 

[mihe7]

Das kann ich nicht sagen, wenn ich nicht weiß, wofür Deine Klassen Model, View, Controller gedacht sind

Mach doch mal ein konkretes Beispiel, dann wird das einfacher. Was ich noch ganz allgemein sagen kann: ich würde das Undo ebenfalls über ein Undo-Model regeln. Die View kennt dann eben zwei Models. Das ist wie z. B. bei JList: ein SelectionModel und ein ListModel.

 

[White_Fox]

Hm...wenn ich das Undo über ein zweites Model mache (wie soll das eigentlich gehen?), dann sehe ich die Daseinsberechtigung des Controllers allmählich nicht mehr.

In der View wird der ganze JavaFX-Kram geregelt und Benutzereingaben werden in Command-Objekte übersetzt.
Das Model enthält die Nutzdaten.
Der Controller führt die Commandobjekte aus und reiht sie in eine Queue ein. Oder auch nicht, da nicht alle Command-Objekte wieder rückgängig zu machen sind (z.B. sowas wie Datenexport).
Die Klassen selber gibt es auch hauptsächlich deswegen, weil es ja irgendwie eine Klasse sein muß. Die eigentliche Strukturierung wollte ich über die Interfaces machen, deswegen gibt es so viele davon.

Ein konkretes Beispiel ist schwierig, hab ja alles wieder umgeworfen. Und wollte erstmal eine einigermaßen brauchbare Struktur schaffen bevor ich wieder Code schreibe.

 

[mihe7]

Muss mal kurz weg, ich antworte evtl. nachher nochmal. Vorher noch schnell:

Hm...wenn ich das Undo über ein zweites Model mache (wie soll das eigentlich gehen?)

Das UndoModel hätte z. B. die Aufgabe "UndoableCommands" zu verwalten und informiert (Observer-Pattern) die View, wenn sich "was tut".

Die View dagegen könnte das Enablen/Disablen der Menüeinträge (Undo/Redo) an die "Properties" des UndoModels binden (bzw. über die Ereignisse steuern).

Die "Action", die beim Ausführen der Menüeinträge ausgeführt wird, wäre im MVC-Pattern ein Controller, der das UndoModel zum Undo/Redo anweist. Das UndoModel kann dann z. B. den letzten Command aus einer Liste (Stack) nehmen und dessen undo()-Methode aufrufen.

 

[White_Fox]

Genau den Mechanismus wollte ich im Controller unterbringen. Ich habe das als Teil der Programmlogik verstanden.

 

[mihe7]

Logik = Model. Aber wie gesagt: MVC = 1000 Meinungen. Wichtig für mich ist: Trennung von Logik und Präsentation, ob das Zeug dann hinterher Model, Controller, oder sonst wie heißt, ist doch völlig unerheblich.

 

[White_Fox]

Dann mach ich das jetzt einfach mal...immerhin hab ich jetzt schonmal einen Plan, das ist mehr als ich beim ersten Versuch hatte.

 

[mihe7]

Wenn Du was konkretes hast, wird sich hier sicher der ein oder andere finden, der dazu eine Meinung hat