JavaFX MVVM Prinzip und Binding

Bitte aktiviere JavaScript!
Ist das jetzt ein ja? :)

Bin zwar kein blutiger Anfänger aber noch immer Anfänger im programmieren. Hatte bisher nur das mvvm genutzt.. Ich arbeite seit 2 Tagen mit Javafx.
Geht das durch als Entschuldigung? :p
 
A

Anzeige




Vielleicht hilft dir unser Kurs hier weiter —> (hier klicken)
Habs mir grad angeschaut. Ist nix anderes als bei mvvm, außer das es keine extra Ebene für die Relays gibt.
Du wirst immer wieder erleben, dass Kleinigkeiten dann große tolle Namen bekommen. Als damals WPF eingeführt wurde, gab es diesbezüglich ein paar Diskussionen mehr in den MSDN Foren....

Generell sehe ich da nicht wirklich große Unterschiede. Du hattest erwähnt, dass Du z.B. die Bindings in dem xml haben willst, damit der Designer darauf zugreifen kann oder so ähnlich. Aber genau das ist doch egal.

Fakt ist doch dass diese Trennung zwischen Designer und Entwickler so in der Form heute gar nicht mehr geht. Die Abhängigkeiten sind hier einfach zu groß. Ich nehme mal die Web Entwicklung als kleines Beispiel:
Bei HTML kann man sehr gut alles an einen Designer geben. Der bekommt ein einmal generiertes statische HTML Dokument, in dem von mir aus alles als reine div Blöcke vorgegeben ist. Und dann kann er ganz frei seine CSS und JS Parts bauen um aus den strukturierten Daten alles aufzubauen, was benötigt wird. Also z.B. Menüs, Tabellen, ...
Aber da kommt schon das Java Script massiv mit rein mit all seinen Problemen. Zeigt also: Das ist kein reiner Designer sondern da muss man auch schon entwickeln.
Aber wie wichtig ist das? Ganz offensichtlich nicht ganz so wichtig, denn davon wurde dann massiv weggegangen:
- Die Single Page Applikationen sind da jetzt groß am kommen. Und zwar in einer Art und Weise, dass da auf Client Seite schon sehr viel abläuft. Daten kommen nur noch über Webservices in die Applikation. Der Server rendert da nichts mehr.
- Und die Entwicklung geht weiter: Schau Dir mal an, was da mit Webassembly kommt. Das ist teilweise fantastisch aber zeigt, das diese Trennung nicht wirklich so wichtig sein kann. Der Designer-Part endet dann doch meist darin, dass nur noch ein css angepasst wird.

Und zurück zu den Bindings: Das ist ja die große Anhängigkeit zu dem Controller (bzw. dem Gegenpart bei MVVM). Der Designer kann nicht frei walten, denn viele Änderungen benötigen Änderungen eben genau dort. Daher würde ich vermuten (Ich habe nie die Situation gehabt, dass es einen Designer gab, der sowas übernommen hätte), dass die Bindings im Code aufzustellen eben doch sinnvoller ist. Denn dann kann der Desiger die Vorgaben entsprechend umsetzen und das Resultat kommt dann zum Entwickler. Und der schaut dann zu, dass er die Bindings erstellt. Anpassungen am Design ohne funktionale Änderungen kann der Designer dann im Nachgang machen

Generell kann man das aber sehen wie man will. Es geht hier um Feinheiten und jeder muss für sich entscheiden, wie er es denn gerne haben möchte.
 
Ich will Java nicht schlecht machen. Aber in diesem Punkt ist es sehr rückständig.
Nicht nur da (wobei das ist nicht immer schlecht sein muss). Und was JavaFX betrifft, bin ich nicht unbedingt dafür bekannt, ein Freund davon zu sein :)

Habs mir grad angeschaut. Ist nix anderes als bei mvvm, außer das es keine extra Ebene für die Relays gibt
Eben. Verschiedene Dinge unterschiedlich zu bezeichnen, ist im Grundsatz auch völlig in Ordnung - so lange es nur darum geht, ein gemeinsames Verständnis über den Namen herzustellen. Die Probleme fangen an, wenn der Name werbewirksam verwendet wird.

Schau Dir mal z. B. JSF an. Es gibt eine XHTML-Datei, in der Du via JSF EL die Properties einer Managed Bean an UI-Komponenten binden kannst. Die Views werden deklarativ in XHTML beschrieben, wobei die entsprechenden Objekte vom Framework instantiiert werden. Kommt Dir ggf. bekannt vor, oder? In JSF ist einfach nur von MVC die Rede. Liegt vermutlich daran, dass es älter als WPF ist.

Wie auch immer, man kann sich ja mal die Frage stellen, was sich besser verkauft: die Millionste Abhandlung über MVC oder das neue MVVM? Das sehe ich ähnlich wie in der Lebensmittelbranche die "verbesserte Rezeptur"; das ist noch nicht mal gelogen, denn es steht ja nicht dabei, für wen sich die Rezeptur verbessert hat :)

Für den nächsten Abschnitt fasse ich mal ein paar Sätze von Dir zusammen:
Ich habe zwar einiges zum Thema MVVM gefunden, allerdings werden dort die Bindings im Code gemacht, was meiner MEinung nach konträr zum System zu MVVM steht.
...
Da kann man auch gleich auf MVVM in Java verzichten, aus oben genannten Gründen.
...
Warum man das nicht im Code machen will? Der Sinn von MVVM ist es, dieses eben nicht zu tun.
Du begründest Dein Ansinnen vordergründig damit, dass der Code sonst nicht einem bestimmten Muster entspricht.

Das ist ein Indiz für das Problem, das ich mit diesen Buzzwords habe: diese führen dazu, dass die Leute nicht mehr nach einer Lösung (z. B. in Form eines Patterns) für ein Problem suchen, sondern sie suchen sich z. B. erst einmal ein Pattern aus und schaffen sich damit das Problem, dem Pattern entsprechen zu müssen/wollen. Gleiches gilt für Architekturen, Sprachen etc.

Es gibt zig Diskussionen im Netz, wo es nur darum geht, ob das jetzt MVC oder MVP ist und ob man MXYZ jetzt richtig angewendet hat oder in irgendeinem Punkt dagegen "verstößt". Dabei ist das doch völlig egal.

Der Designer kann sich dabei zu 100% um das Design kümmern ohne den Code anzutasten.
Das kann der Designer sogar noch besser, wenn in seiner XML-Datei gar keine Bindings vorkommen. Eine 100 %-ige Unabhängigkeit kann es nicht geben.
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben