WPF: XAML oder Code-Behind?

[kai-carsten]

Hallo!

Beim Befüllen dutzender Comboboxen und Scheitern in XAML (s. http://entwickler-forum.de/showthrea...567#post228567 ) taucht für mich wie schon einge Male folgende Frage auf:

Wofür soll ich ehrgeizig Dinge in XAML programmieren, die ich auch im Code-Behind coden kann?

Gerade als WPF-Anfänger dauert es in XAML länger, an jeder Ecke lauern Probleme und was bei umfangreicheren Tests noch an Fehlern zum Vorschein kommt, weiß ich heute noch gar nicht. Da ist der gewohnte (VB-)Code doch wesentlich berechenbarer.

Wo sind die konkreten Vor- und Nachteile?

Ich hoffe ich bekomme ein paar Meinungen, da diese Frage für mich zukünftig auch von grundsätzlicher Bedeutung sein wird.

Vielen Dank!

Gruß

Kai

[fanderlf]

...Da ist der gewohnte (VB-)Code doch wesentlich berechenbarer....

Ich habe mir für die Zukunft auch WPF vorgenommen. Privat mache ich derzeit auch ein kleines Projekt. Dort werde ich auch auf jeden Fall WPF einsetzen.
Ich denke das Problem ist, dass man sich einfach noch nicht an die Denkweise von WPF gewöhnt hat.
Wie lange programmierst Du schon GUIs die vom Schema wie Windows Forms sind? Ich denke die GUIs hatten bis jetzt immer die gleich Struktur. Allerdings ist Windows Forms z.B. nicht sehr mächtig.
Ob es natürlich in Deinem konkreten Beispiel jetzt unbedingt Sinn macht auf Biegen und Brechen alles in XAML zu code sei mal dahin gestellt. Auch Code Behind ist ja noch Interface Logik. Allerdings sehe ich die Daten eines Lookups nicht im Interface, sondern eher in der Business Logik bzw. dem Data Access. Warum baust Du Dir nicht eine kleine Klasse die genau einen Monat repräsentiert und übergibst eine Liste davon (oder auch einfach nur eine Liste von Strings) an die GUI und bindest diese an die ComboBox.
Wenn das ein eigenständiges Control werden soll, fände ich es aber auch nicht so schlimm, wenn der Code im Code Behind stehen würde. Dann wäre es ja wieder Teil des Controls selbst und hätte nichts mit Business Logik zu tun.

Grüße
FanderlF

[gfoidl]

Hallo,

wie fanderlf geschrieben hat ist das Wesentliche die Trennung von UI-Ebene und Logikebene. Zur UI-Ebene gehören sowohl Xaml als auch die Code-Behind der jeweiligen View. Von diesem Standpunkt ist es egal ob die UI in Xaml oder Code-Behind erstellt wird.

Einen Schritt weiter gedacht und es wird MVVM angewandt so ist in der Tat kein Code-Behind-Code notwendig da "alles" über Daten- und Befehlsbindung funktioniert.

Ich sehe einen praktischen Vorteil in Xaml darin dass es deklarativ ist. Um zB einen Xaml-1-Zeilen in Code zu erreichen wären viele Zeilen notwendig. Das lässt sich auch in der MSDN ganz gut verfolgen wo Xaml und Code dargestellt werden.

In Hinsicht auf Globalisierung ist von Vorteil kein Codebehind zu haben bzw. alle Strings im Xaml zu haben.

Unabhängig von Xaml vs. Codebehind:
Natürlich kannst du mit WPF fast wie bisher arbeiten. Ich denke jetzt wäre aber die passende Möglichkeit mit alten (und vielleicht falschen Gewohnheiten?) zu brechen und es gleich "richtig" machen. Und dazu gehört eben das Konzept dass in WPF "alles" per Bindung gemacht wird.
Das habe ich im anderen Bsp. auch schon so gezeigt. Hier waren halt die Daten direkt in der Xaml deklariert da sie sich eh nicht ändern werden. Ansonsten siehe den obigen Link für MVVM.


mfG Gü

[fanderlf]

Hinzufügen möchte ich noch, dass ich WPF für wesentlich mächtiger als Windows Forms halte. Wichtige UI Patterns werden direkt unterstützt (Commanding, MVVM...). Ausserdem ist das DataBinding und DataTemplating in WPF sehr viel einfacher zu handhaben als in Windows Forms. Es ist eben einfach nur anders und neu. Wenn man längere Zeit damit gearbeitet hat frägt man sich bestimmt wie man früher nur mit Windows Forms arbeiten konnte.
Ähnlich geht es bestimmt auch Leuten die von der rein prozeduralen Programmierung (z.B. in C) auf objektorientiert Programmierung umsteigen. Auch hier denkt man sich anfangs: Brauche ich das alles? Ich kann das mit meinen alten Methoden doch viel schneller erledigen. Der Mensch ist ein Gewohnheitstier
Ob jetzt natürlich WPF der Weisheit letzter Schluss ist sei mal dahingestellt, aber ich denke es ist ein neues und mittlerweile auch brauchbares Framework für UIs.
Dazu kommt noch dass XAML sehr sehr mächtig ist. Es ist ja nicht nur eine GUI Beschreibungssprache, sondern eine deklarative Sprache um Objekte zusammenzusetzen. Man kann praktisch in XAML alle beliebigen Objekte zusammensetzen, ähnlich einem IoC Container.

[gfoidl]

Hallo,

Wenn man längere Zeit damit gearbeitet hat frägt man sich bestimmt wie man früher nur mit Windows Forms arbeiten konnte.

Ja, so ist es

Ich würd XAML nicht unbedingt erzwingen wollen sondern lass es mit der Zeit kommen. Schau dir die Beispiele an die es im Netz gibt und verändere diese nach belieben - achte darauf was sich ändert, usw.
XAML kannst du spielerisch lernen


mfG Gü

[kai-carsten]

Danke für Eure Meinungen.

Die Trennung von Design und Logik hört sich immer ganz toll an und liest man im Zusammenhang mit WPF ja auch ständig.

Wenn es aber in der Praxis so aussieht, dass ich nicht nur länger brauche, sondern teilweise auch gar nicht zum Ziel komme, wie bei meinem letzten ja eher kleinen Problem, dann wird mir das alles zu philosophisch.

Ich glaube ich bin dann im Einzelfall doch zu pragmatisch und werde zukünftig im Zweifel den Weg des geringeren Widerstandes gehen.

Ich habe ja nach konkreten Vor- und Nachteilen gesucht, denke aber mal es betrifft hauptsächlich die Übersichtlichkeit und Wartbarkeit. Aber dies kann ich auch ohne MVVM und Ähnlichem in einem für mich akzeptablen Mass erreichen (bin eh Einzelkämpfer).

Letztendlich muss ich ja irgendwann auch mal Ergebnisse vorweisen, auch wenn das für manche sicherlich zu kurz gedacht scheint.

Gruß

Kai

[gfoidl]

Hallo,

wie bei meinem letzten ja eher kleinen Problem

Ich weiß nicht was beim anderen Bsp. nicht funktioniert - bei mir gings und den Code habe 1:1 ins Forum gepostet - aber das gehört in den anderen Thread denn es hier Offtopic

Trennung von Design und Logik

Das ist schlichtweg die Basis für jeden guten Entwuft. Alles andere ist Müll!
Dass man das erst mit Erfahrung merkt oder wenn man bereits einmal kräftig auf die Schnauze gefallen ist da ein Monolith nicht wart-/änderbar, usw. ist versteht sich irgendwie von selbst. Anfänglich hat wohl jeder das falsch gemacht.

Ich habe ja nach konkreten Vor- und Nachteilen gesucht, denke aber mal es betrifft hauptsächlich die Übersichtlichkeit und Wartbarkeit.

Ja - und das sind ja gerade (für mich zumindest) 2 gewichtige Argument.

Aber dies kann ich auch ohne MVVM und Ähnlichem in einem für mich akzeptablen Mass erreichen

Hier will/muss ich festhalten dass Muster (Pattern) keine Pflicht sind, sondern ein Satz bewährter Regeln oder ein Leitpfad. Muster denkt sich auch niemand aus, sondern die kristallisieren sich mit der Zeit heraus.

Für die Trennung von Design und Logik gibt es verschiedensten Muster - MVC, MVP, ... - von denen jedes ihre "Abwandlungen" hat und natürlich auch Vor- und Nachteile. Die Abwandlungen gibt es eben daher da ein Muster nicht definiert "0! = 1" sondern "nur" ein Leitfaden ist.

MVVM ist auch nur ein Leitfaden der sich für die Verwendung mit WPF als nützlich herausstellt bzw. dafür aus dem MVP-Muster hervorgegangen ist. Natürlich ist es zustätzlicher Aufwand sich in die Arbeitsweise nach MVVM (ich habe ganz bewusst nach MVVM -> nach dem Leitfaden) einzuarbeiten, aber langfristig lohnt sich das sicher. Alleine schon deshalb da (fast) kein UI-Code(behing) mehr geschrieben werden muss.

Für mich ist die Trennung von UI und Logik (oder allgemein die Trennung der Anliegen) quasi ein Muss. Wie oben bereits erwähnt wollte ich das anfänglich auch nicht wahrhaben und dachte ähnlich wie du. Jetzt siehst du ja wie sich meine Denkweise in dieser Hinsicht geändert hat. Vielleicht lässt du dich (nochmal) auf MVVM ein - mit der Zeit wirst du es schätzen lernen


mfG Gü

[kai-carsten]

Danke für Dein Statement!

Ich weiß nicht was beim anderen Bsp. nicht funktioniert - bei mir gings und den Code habe 1:1 ins Forum gepostet - aber das gehört in den anderen Thread denn es hier Offtopic

Das hatte ich in dem anderen Thread geschrieben: Die Auswahl per Tastatur funktioniert so leider nicht, auch nicht in Deinem Beispiel.

Gruß

Kai

[gfoidl]

Hallo,

OK - mein Fehler. Ich werde halt alt


mfG Gü