Die Diskussion ist bei uns hochgeschlagen. Wie versprochen, hier mal eine Zusammenfassung unserer Positionen.
Was die WPF ist, sparen wir uns. Das kann man flächendeckend vielerorts nachlesen.
Die Trennung von User Interface und Programmcode
Hervorgehoben sei uns unserer Sicht die Trennung vom User Interface (nachstehend als UI bezeichnet) und vom dahinter gelegten Code.
Bei der Verwendung von Windows Forms ist es ein Vorgang: Programmierer zeichnet den Button und legt im Programmcode fest, was auf dem Button zu erscheinen hat, was geschieht, wenn der Button gedrückt wird und welche Aktionen ausgeführt werden. UI und Programmcode sind also quasi ein Arbeitsgang und werden zusammen behandelt.
Bei WPF lässt sich das UI komplett vom Programmcode trennen.
Hier werden z.B. der Button und natürlich alle anderen Controls, vollkommen separat in einer XAML Datei definiert. Design / Aussehen. Beschriftung. Ja sogar die Aktion, was zu tun ist.
Der Programmierer mit seinem Sourcecode in C# (oder VB.NET) kommt hier später ins Spiel: hinter der XAML Datei liegt als Code-of-Behind eine Programmdatei hier kann er das vordefinierte UI mit Programmzeilen und Leben füllen.
Vergleichen wir es mit einem Hausbau: Unter XAML werden Außenansicht und Raumaufteilung, Dach und Außenwände errichtet. In dahinter gelegten Programmdateien werden die Zimmer tapeziert, Rohre und Leitungen verlegt und Nutz- sowie Bewohnbarkeit geschaffen. Außenaufbau und Innenausbau sind getrennt und können entsprechend als separate Arbeitsschritte vollzogen werden.
So lassen sich unter WPF Optik im UI und Programmcode auch wunderbar trennen.
Der nun häufig genannte Vorteil, Designer könnten getrennt vom Programmierer das GUI erstellen und Programmierer hauchen dem Code später Leben ein … mag irgendwo existieren. Vielleicht auch irgendwann einmal. Doch wir finden diese Betrachtungsweise momentan theoretisch: in den meisten Teams dürften keine Designer mit XAML Kenntnissen zu finden sein. Die uns bekannten Designer z.B. sind Experten in Photoshop, können tolle Fotos für Internet und WordPress aufbereiten, Master für Powerpoint definieren, haben aber keine Kenntnisse in XAML – und finden das Thema überaus langweilig, wenn man ihnen die entsprechenden Tools vorstellt.
Warum dann doch WPF?
Ob Business-Software wirklich 3D Grafiken, Dirext X und animierte Buttons mit Video drauf benötigt, sei dahin gestellt.
Vektor Grafiken? Nun gut, für Schule, Studium und Lehre mag das ein Thema sein. Oder wenn man Werbebilder so vergrößert, dass sie auf die Plane eines LKW passen.
Eine Desktop Anwendung mit SQL Datenbindung von Windows Forms auf WPF zu portieren… – Warum?
Es erscheint uns etwas sinnfern, denn 1) bietet Microsoft selbst unter Windows Forms mehr und fortgeschrittene User Controls an als unter WPF vorhanden sind (z.b. das Datagridview) und 2) gibt es für Windows Forms haufenweise Drittanbieter mit ansprechender Optik, z.B. DOT NET BAR vom DEVComponents.
Ein kurzes Schmankerl am Rande erzählt: Als wir mal Anfang der 2000 Jahre mit VB.NET anfingen, boten uns die Windows Forms für Darstellung von Daten in Tabellen das DataGrid Control. Das war so .. nun ja. Ein paar Versionen später kam das DataGridView hinzu. Das war schon überaus mächtig und konnte Massendaten auf vielschichtige Art und Weise darstellen und wird heute noch von uns verwendet. Bei Drittanbietern als Control sogar ganz mächtig aufgepeppt! Bei WPF sind wir aktuell nun wieder beim Datagrid angelangt.
WPF Anwendungen sind unser Ansicht nach jedoch sinnvoll, wenn ein komplett neues Design verfolgt werden soll. Also keine reine Datenbankanwendung mit Tabellendarstellung – sonder ein Grafiktool, um ein Bild darzustellen, es mit einer Sache zu verknüpfen, es zu ändern. Oder einen Film. Oder irgend etwas, das Spezialsachen benötigt, wie z.b. mathematische Funktionalitäten, Kurvendiskussionen uvam.
Doch das wäre nur unsere heutige Ansicht. Stellen wir uns mal die ideale Welt von Morgen vor: eine Welt in der XAML als Beschreibung für ein User Interface überall Einzug gehalten hat.
WPF in der Welt von Morgen!
Jetzt wird es spannend! Dann braucht man eigentlich nur noch einen Compiler und kann die unter XAML definierte Oberfläche auf einem Android Smartphone verwenden. Oder auf den Panel Screens im Auto. Auf Industrie PCs. Unter Linux.
Kurzum: wenn es Microsoft gelänge diese WPF Konstruktion der XAML UI Definitionen auch für andere Hardwareplattformen nutzbar zu machen, hätte man auf einen Schlag unabhängige grafische Benutzeroberflächen für (fast) jede Art von Hardware. Nur noch der hinterlegte Arbeitscode muss evtl ausgetauscht und ersetzt werden. 30…50 % der Programmierung wären vorhanden und schon gleich. Der alte Programmierer-Traum: eine Anwendung, die überall läuft, wäre Realität!
In dieser Welt würde WPF und XAML GUI Erstellung dann zu einem mächtigen, absolut plattformunabhängigen Tool.
Ob das eintritt? Wissen wir nicht. Doch möglich wäre es. Deswegen erscheint es nicht falsch, sich mit WPF zu beschäftigen und bereits jetzt die eine oder andere Anwendung zu realisieren. Um Erfahrungen zu sammeln, die sich dann in der Zukunft auszahlen werden. Aber bitte keine Anwendungen, die unter WPF genauso aussehen wie unter Windows Forms. Das wäre Verschwendung. Von Arbeits- und Lebenszeit.
Literatur Hinweis:
Huber: Windows Presentation Foundation, 5. Auflage. Rheinwerk Verlag.
