Umsetzung von MVC in der Praxis

[dzim]

Hallo zusammen,

mich würde - wie man vielleicht am Titel erkennt - interessieren, wie strikt es in der GUI-Programmierung eigentlich aus eurer Sicht Sinn macht, die Konzepte zu trennen.
Versteht mich nicht falsch, ich trenne auch so viel es eben geht, lege größere Operationen in Jobs ab, u.s.w.
Was ich aber beim Entwickeln meiner Editoren nie weit auslagere sind zum Beispiel die Listener (mein private Klassen innerhalb der entsprechenden GUI-Klasse):
In meinen Augen hat es den Vorteil, dass ich schnell mein Verhalten Implementieren kann, und einfachen Zugriff auf alle notwendigen Daten habe. Ich mach das meist so, das nur ein Listener existiert, der halt je nach Quelle anders reagiert.
Ein Nachteil ist aber ein mitunter stark aufgeblasener Quellcode - bis zu 1500+ Zeilen für einen Editor zum Beispiel.

Was ist da eure Erfahrung?
Wo ist es sinnvoll zu trennen, wo nicht?

 

[noisebreath]

Also an sich sehe ich dass ähnlich. MVC implementiere ich bei der Gui aber meine Listener lasse ich auch in den dazugehörigen Panelclasses. Ich mach dann meistens noch eine WindowSuperClass von der die Panels erben, da meistens gewisse funktionalitäten für alle (bzw die meisten) gleich sind.
Was genau willst denn da noch wissen?

 

[noisebreath]

du solltest einfach schauen dass die mvc classen strikt getrennt sind. meines erachtens sind listener und sonstige panelspezifische implementierungen nicht teil der mvc.
Dinge die zum panelhandling gehören etc schon.

 

[dzim]

Was mich halt nur manchmal stört ist eine doch noch relativ starke Verzahnung von Modell und View - das sich, wie im Fall der Listener nicht alles trennen läßt, liegt vermutlich in der Natur der Sache.
Ein Beispiel:
Ich habe ein XML Schema, aus dem ich mir mit xjc ein entsprechendes JAXB-Modell gebaut habe. Das sind Konfigurationsdateien. Meine GUI bildet nun dieses Model graphisch ab - so weit so gut, aber wenn ich jetzt halt in der einen Tabelle was hinzufüge/lösche, geschieht das live im Modell...
Mein Problem ist: Wie sehr müssen die Konzepte getrennt werden? Sollte der Contoler diese Änderungen an dem Model vornehmen, oder ist es legetim, das dierekt von den GUI-Handlern machen zu lassen?
Letzten Endes sind das Fragen von geringer Signifikanz, aber vielleicht ließe sich der Code ja übersichtlicher gestalten, wenn ich noch viel mehr die Konzepte trenne.

 

[Marco13]

Da war neulich eine ausführlichere Diskussion drüber: http://www.java-forum.org/allgemein...controller-ein-software-pattern-beispiel.html

Wenn du unter "Verzahnung" nur verstehst, dass die (ggf. anonymen) Listener, die direkt in der GUI-Klasse stehen, direkt auf's Modell zugreifen, dann ist das meiner Meinung nach(!!!) OK. Ich war mir da auch etwas unsicher, aber obiger Thread hat für mich(!!!) nichts zutage gebracht, was dagegen spricht. In diesem Sinne war jeder dieser Listener einfach ein "kleiner Controller".

Allerdings ist klar, dass das Modell die View nicht direkt kennen sollte.
(Ob das Modell die Daten vollkommen abstrakt liefern sollte, oder schon an die "Bedürfnisse" einer bestimmten GUI angepasst sein sollte, war noch ein Punkt, zu dem es einige Diskussionen gab ... ich war eher für ersteres, weil es eine allgemeinere Beschreibung des Modells ermöglicht, andere haben eher letzteres propagiert... da möge sich jeder selbst seine Meinung drüber bilden )

 

[dzim]

Ok, danke für eure Antwort, ich les mir gerade den genannten Thread mal durch.
Ich bin jedenfalls erst mal froh zu hören, dass ich nicht der einzige bin, der so wie ich vorgeht :-D
Ich werde einfach auch in Zukunft versuche, dort wo es wirklich Sinn macht, die Trennung der Konzepte beizubehalten, aber werde wohl auch in Zukunft nicht damit übertreiben (nur solche riesigen, unübersichtlichen GUI-Klassen mit mehr 1500 Zeilen will ich eigentlich so gut es eben geht vermeiden).

Vielen Dank jedenfalls!

 

[Wildcard]

@dzim
Sicher das du hier richtig bist? Ich sehe nämlich nichts OSGi/RCP zugehöriges.
Wo hättest du den Thread denn gerne?

Ich habe ein XML Schema, aus dem ich mir mit xjc ein entsprechendes JAXB-Modell gebaut habe.

Nimm EMF


EDIT: falls du hier gepostet hast, weil es konkret um zB ein Eclipse Product geht, dann solltest du definitiv auf EMF wechseln, denn sowohl EMF, als auch JFace unterstützen Data Binding, darum müsstest du dich also gar nicht mehr kümmern.

 

[dzim]

Hm... Genau betrachtet hast du wohl recht @Wildcard.
Wenig RCP-related Infos, die ich gegeben hab...

Du sagst, ich soll emf verwenden - das ist eine gute Idee für mein Frontend, mein Backend allerdings hat nix mit Eclipse am Hut, ausser dass ich die entsprechenden Projekte zu Plugins umgewandelt habe - eben Core-Plugins, die auch noch mit minimalen Anforderungen teilweise über CLI betrieben werden.

Ich nutze viele der Modelle der Core-Umgebung, diese ist allerdings durchaus als unabhängig zu betrachten, da wollte ich nicht mit EMF anfangen...

Da ich bei uns in der Firma einer der wenigen bin, die überhapt Java entwickeln und auch der Einzige, der RCP macht, habe ich mich aus Zeitgründen nie an EMF und Databinding rangetraut, weil ich dann in der Zeit vermutlich andere Sachen schleifen lassen muss...
Nur so als neugierige Anfrage: Wären Lars Vogels Tutorials zu EMF und Databinding hilfe genug um einen Einstieg in diese Materie zu bekommen (einen Tag oder jeweils ein paar Stunden könnte ich sicher bazwacken um mich da reinzufinden).

 

[Wildcard]

Du sagst, ich soll emf verwenden - das ist eine gute Idee für mein Frontend, mein Backend allerdings hat nix mit Eclipse am Hut, ausser dass ich die entsprechenden Projekte zu Plugins umgewandelt habe - eben Core-Plugins, die auch noch mit minimalen Anforderungen teilweise über CLI betrieben werden.

EMF Modelle sind komplett Eclipse unabhängig und auch nicht auf Java festgeschrieben (gibt zB einen C# Port).
Du kannst dir allerdings zusätzlich ein edit und ein editor plugin aus einem Meta Modell generieren. Der Editor ist Eclipse spezifisch, das edit PlugIn nicht, hat aber ein paar sehr hilfreiche Utility Klassen wenn es in Eclipse betrieben wird.