Angenommen ich will ein super sauberes Programm schreiben, welches auf dem mvc pattern aufbaut.
nun hab ich in meiner view aber ganz ganz viele knöpfe und was weiß ich, vielleicht ein großes menu oder sowas.
Die Funktionen an sich gehören alle in den Controller, ich denke das ist klar. Aber: Wie macht man das bei so vielen Aktionen?
Ergibt es sinn zB pro “sinnbereich” einen action listener zu haben, und dann mit if(actionCommand.equals(…)) alle fälle abfragen?
Die möglichen actionCommands vielleicht als final static String 's im Controller speichern? Enums gehen hier ja nicht, weil actionCommands
nur strings sein können… oder irre ich mich da?
oder sollte jedes ding seinen eigenen action listener haben? In so einem fall… wie kommen die elemente in der view dann an ihre
listener? Ich würde dann eine Menge an ActionListenern übergeben, vielleicht eine Map… wie sollten dann die keys sein, um die listener
dann auch richtig zuzuordnen? Diese Menge müsste ja auch unter den Klassen geteilt werden, die etwas mit der gui zu tun haben… vorausgesetzt
ich klatsche nicht die ganze gui in eine klasse… (pfui, macht man ja nicht ^^)
Wie regelt ihr soetwas? Wie macht man das möglichst “professionell” ?
Verpass jedem Ding einen eigenen, anonymen Listener. Der kann auf alle Elemente der View zugreifen und gut ist. Ja, das ist MVC weil dieser Anonyme Listener ein eigenes Objekt ist, auch wenn er im gleichen File wie die View steht.
Eine Konstruktion mit vielen if-actionCommands erzeugt hässlichen Spaghetti code der nochdazu schlecht zu warten ist.
Die Frage passt auch super zu meinem Projekt. Gut, dort ist die Menge an Inputs doch noch überschaubar, aber ich denke ich hätte die gleiche Frage gestellt.
Hier vielleicht mal meine Idee :
Controller erstellt View und übergibt this
in View erhalten alle Inputs einen anonymen Listener der dann entsprechende Methoden auf die Controller-Referenz anwendet
da dem Controller View bekannt ist können darüber Änderungen wieder über den EDT eingebracht werden ohne das diese in den Listenern stehen müssen
Verbindet man das ganze über Interfaces (ja, ich mag die einfach …) erhält man sogar eine schön modulare Variante in der man dann Logik oder GUI auswechseln kann ohne das man an der jeweils anderen Komponenten rumbasteln muss.
das führt dann also dazu, das view letzten endes doch den controller kennt?
was hat das denn mit „eigenes objekt“ zu tun? wenn er in einer view klasse erzeugt wird, und zugriff auf den controller hat, spricht das doch gegen mvc…?
Swing und die Komponenten ansich sind nach dem MVC-Pattern gebaut. Ein Textfield ist ein Komplettes MVC.
Man kann aber auch MVC im Kontext einer Anwendung sehen und Abhängig von der Art der Anwendung funktioniert das Zusammenspiel unterschiedlich. Allerdings gibt es bei MVC immer die Drei Komponenten.
Die View bekommt eine Reference auf den Controller. Der Actionlistener ruft Methoden auf dem Kontroller auf.
Das Ergebnis ist dann eine Veränderung des Models und eine Änderung der View, bzw. des View-Models, wenn die View nach MVC gebaut ist.
Vgl. MVVM als einen weiteren Ansatz im .net Umfeld.
Allerdings wird oft, mich eingeschlossen, ein ActionListener als Controller angesehen, was er allerdings nicht ist. Er ist ein Teil der View.
ModelImpl model = new ModelImpl(view);
ControllerImpl controller = new ControllerImpl(model);
view.addObserver(controller);
view.start();```
Kann aber schon sagen, das ist falsch.
View kennt Controller - Controller kennt Model - Model kennt View und View kennt Model und View registriert sich bei Model (Model ruft quasi Methode von View auf). <-> kein Kauderwelsch
(Best Practice) und "professionell" <-> da hapert es bei mir noch ein bisschen.
Jedenfalls soll jede "Komponente" und ihre Implementierung ohne Einfluss "mit den anderen" Komponenten austauschbar sein.
So, nun meine 50-Cent. Grüßle.
MVC definiert keine Verknüpfungen sondern Komponenten.
Die Komponenten sind Model - View - Controller.
Und das war es. Auch wenn ich es ungern sage CB liegt da schon näher dran.
Die Verknüpfung untereinander, ist in verschiedene Unterkategorien einzuordnen.
Passiv View zum Beispiel. Hier kennen sich View und Model nicht. Die gasamte Kommunikation läuft über den Controller, der mit beiden kommuniziert.
Es ist aber genauso gut drin das Model und View per Databinding miteinander kommunizieren und der Controller nur wichtige Sachen regelt. Also ein Supervising Controller.
Und je nachdem was man vorhat, bzw. welche Rahmenbedingungen es gibt muss man sich eine Variante herauspicken.
Databinding ist z.B. in einer Webanwendung schwer umzusetzen.
Hier kann z.B. mit AngularJS in Richtung MVVM gegangen werden.
Ich empfehle mal den Englischen Wikipediaeintrag als Einstieg, der sich vom Deutschen stark unterscheidet.
Nein, die View kennt den Controller eben nicht, es sei denn du merkst dir die Listener Instanz in einer eigenen Membervariable in der View. Wer wen kennt ist eigentlich nebensächlich, es kommt auf eine saubere Trennung des Codes in die jeweiligen Verantwortungsbereiche an. Meistens ist im Controller nicht sehr komplexer Code, deshalb kann man ihn sehr kurz halten - mir fällt eigentlich kein Beispiel ein wo ein Controller mehr als 100 Zeilen Produktivcode brauchen sollte. Wenn das so ist, ist es nämlich meistens besser die jeweiligen Codestellen wieder an andere Klassen auszulagern z.B Validator.
Ja, das MVC… Uhrzeitbedingt nur der kurze Hinweis: Für fast alles, was mit ActionListenern zu tun hat, bieten sich (wenn man es “professionell” machen will) Actions an: How to Use Actions (The Java . (Die Frage nach der Aufteilung, und was denn eigentlich ein “Controller” ist, ist damit aber nur indirekt und/oder teilweise beantwortet…)
Ja, alles kennt alles ist sicher kein mvc…[/QUOTE]
Erst ja, dann nein, und jetzt auf Beef aus? MVC-Design-Pattern ist überall nachzulesen, weil es das gefühlt schon 50 Jahre gibt.
Sei doch mal freundlich und sag, was du vor hast…
Also View registriert Controller auf seine/ihre Komponenten, Controller sagt Model eine Änderung, und Model sagt dann View Bescheid, hat sich was geändert, so läuft das. (ungefähr)
Wichtig ist halt, was beide auch schon sagen, Austauschbarkeit/Erweiterbarkeit der einzelnen “Komponenten”.
kennt, hat, besitzt, erbt von (ist), implementiert <-> aber das kommt später, vermute ich mal. Sind deine Fragen jetzt “und/oder teilweise” beantwortet? Ich geb mir ja mühe.
Wenn man jetzt nicht mit Swing arbeitet, sondern mit JavaFX (was ich jedem empfehlen würde, der jetzt was mit GUIs macht),
geht das in Richtung WPF und man hat immerhin schon eine etwas losere Struktur gegeben.
Die Komponenten werden dann über Injection in den Controller geladen, zumindest wenn sie ein gültige fx:id haben.
Wer es noch etwas mehr in Richtung DI haben will, kann Afterburner.fx verwenden.
Vorteil ist immerhin, dass der Controller die View als Ganzes nicht kennt, sondern nur die Komponenten, die bei ihm registriert sind,
quasi MasterController, mit welchem man auch spezifische Controller oder Listener an die Komponenten binden kann bei der Initialisierung.
Ich sage mal so, im Grunde kann man den Aufbau sowieso brechen, über indirekte Assoziationen.
Wer den Controller etwas aus dem Spiel lassen möchte, benutzt ihn nur um ein direktionales oder bidirektionales binding zwischen
einer Komponente und irgendeinem internen DT anzumelden. (bind)
Ja, View soll austauschbar sein, Kopplung und Kohäsion und so, aber wie professionell soll denn sein, vielleicht hab ich ja mit dem Thema was verwechselt…
Ich verstehe dein Problem nicht, CB. ^^
Wieso fühlst du dich jetzt angegriffen?
Bin ich jetzt total bescheuert, oder ist das murks was du da geschrieben hast?
Model darf View nicht kennen. Das ist doch der Sinn von mvc - das man das trennt.
eben, austauschbarkeit wird aber nur dadurch garantiert, das view und model völlig unabhängig von einander laufen.
Nur der Kontroller ist dazu da, Kommunikation zwischen den beiden stattfinden zu lassen…
