Die Diskussion ist bei uns hochgeschlagen. Wie versprochen, hier mal eine Zusammenfassung unserer Positionen.<\/p>\n
Was die WPF ist, sparen wir uns. Das kann man fl\u00e4chendeckend vielerorts nachlesen.<\/p>\n
Die Trennung von User Interface und Programmcode<\/strong><\/p>\n <\/p>\n Hervorgehoben sei uns unserer Sicht die Trennung vom User Interface (nachstehend als UI bezeichnet) und vom dahinter gelegten Code.<\/p>\n 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\u00fcckt wird und welche Aktionen ausgef\u00fchrt werden. UI und Programmcode sind also quasi ein Arbeitsgang und werden zusammen behandelt.<\/p>\n Bei WPF l\u00e4sst sich das UI komplett vom Programmcode trennen.<\/p>\n Hier werden z.B. der Button und nat\u00fcrlich alle anderen Controls, vollkommen separat in einer XAML Datei definiert. Design \/ Aussehen. Beschriftung. Ja sogar die Aktion, was zu tun ist.<\/p>\n Der Programmierer mit seinem Sourcecode in C# (oder VB.NET) kommt hier sp\u00e4ter ins Spiel: hinter der XAML Datei liegt als Code-of-Behind eine Programmdatei hier kann er das vordefinierte UI mit Programmzeilen und Leben f\u00fcllen.<\/p>\n Vergleichen wir es mit einem Hausbau: Unter XAML werden Au\u00dfenansicht und Raumaufteilung, Dach und Au\u00dfenw\u00e4nde errichtet. In dahinter gelegten Programmdateien werden die Zimmer tapeziert, Rohre und Leitungen verlegt und Nutz- sowie Bewohnbarkeit geschaffen. Au\u00dfenaufbau und Innenausbau sind getrennt und k\u00f6nnen entsprechend als separate Arbeitsschritte vollzogen werden.<\/p>\n So lassen sich unter WPF Optik im UI und Programmcode auch wunderbar trennen.<\/p>\n Der nun h\u00e4ufig genannte Vorteil, Designer k\u00f6nnten getrennt vom Programmierer das GUI erstellen und Programmierer hauchen dem Code sp\u00e4ter Leben ein \u2026 mag irgendwo existieren. Vielleicht auch irgendwann einmal. Doch wir finden diese Betrachtungsweise momentan theoretisch: in den meisten Teams d\u00fcrften keine Designer mit XAML Kenntnissen zu finden sein. Die uns bekannten Designer z.B. sind Experten in Photoshop, k\u00f6nnen tolle Fotos f\u00fcr Internet und WordPress aufbereiten, Master f\u00fcr Powerpoint definieren, haben aber keine Kenntnisse in XAML – und finden das Thema \u00fcberaus langweilig, wenn man ihnen die entsprechenden Tools vorstellt.<\/p>\n Warum dann doch WPF?<\/strong><\/p>\n Ob Business-Software wirklich 3D Grafiken, Dirext X und animierte Buttons mit Video drauf ben\u00f6tigt, sei dahin gestellt.<\/p>\n Vektor Grafiken? Nun gut, f\u00fcr Schule, Studium und Lehre mag das ein Thema sein. Oder wenn man Werbebilder so vergr\u00f6\u00dfert, dass sie auf die Plane eines LKW passen.<\/p>\n Eine Desktop Anwendung mit SQL Datenbindung von Windows Forms auf WPF zu portieren\u2026 – Warum? Ein kurzes Schmankerl am Rande erz\u00e4hlt: Als wir mal Anfang der 2000 Jahre mit VB.NET anfingen, boten uns die Windows Forms f\u00fcr Darstellung von Daten in Tabellen das DataGrid Control. Das war so .. nun ja. Ein paar Versionen sp\u00e4ter kam das DataGridView hinzu. Das war schon \u00fcberaus m\u00e4chtig und konnte Massendaten auf vielschichtige Art und Weise darstellen und wird heute noch von uns verwendet. Bei Drittanbietern als Control sogar ganz m\u00e4chtig aufgepeppt! Bei WPF sind wir aktuell nun wieder beim Datagrid angelangt.<\/p>\n WPF Anwendungen sind unser Ansicht nach jedoch sinnvoll, wenn ein komplett neues Design verfolgt werden soll. Also keine reine Datenbankanwendung mit Tabellendarstellung \u2013 sonder ein Grafiktool, um ein Bild darzustellen, es mit einer Sache zu verkn\u00fcpfen, es zu \u00e4ndern. Oder einen Film. Oder irgend etwas, das Spezialsachen ben\u00f6tigt, wie z.b. mathematische Funktionalit\u00e4ten, Kurvendiskussionen uvam.<\/p>\n Doch das w\u00e4re nur unsere heutige Ansicht. Stellen wir uns mal die ideale Welt von Morgen vor: eine Welt in der XAML als Beschreibung f\u00fcr ein User Interface \u00fcberall Einzug gehalten hat.<\/p>\n WPF in der Welt von Morgen!<\/strong><\/p>\n Jetzt wird es spannend! Dann braucht man eigentlich nur noch einen Compiler und kann die unter XAML definierte Oberfl\u00e4che auf einem Android Smartphone verwenden. Oder auf den Panel Screens im Auto. Auf Industrie PCs. Unter Linux.<\/p>\n Kurzum: wenn es Microsoft gel\u00e4nge diese WPF Konstruktion der XAML UI Definitionen auch f\u00fcr andere Hardwareplattformen nutzbar zu machen, h\u00e4tte man auf einen Schlag unabh\u00e4ngige grafische Benutzeroberfl\u00e4chen f\u00fcr (fast) jede Art von Hardware. Nur noch der hinterlegte Arbeitscode muss evtl ausgetauscht und ersetzt werden. 30…50 % der Programmierung w\u00e4ren vorhanden und schon gleich. Der alte Programmierer-Traum: eine Anwendung, die \u00fcberall l\u00e4uft, w\u00e4re Realit\u00e4t!<\/p>\n In dieser Welt w\u00fcrde WPF und XAML GUI Erstellung dann zu einem m\u00e4chtigen, absolut plattformunabh\u00e4ngigen Tool.<\/p>\n Ob das eintritt? Wissen wir nicht. Doch m\u00f6glich w\u00e4re es. Deswegen erscheint es nicht falsch, sich mit WPF zu besch\u00e4ftigen 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\u00e4re Verschwendung. Von Arbeits- und Lebenszeit.<\/p>\n Literatur Hinweis:<\/p>\n
\nEs 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\u00fcr Windows Forms haufenweise Drittanbieter mit ansprechender Optik, z.B. DOT NET BAR vom DEVComponents.<\/a><\/p>\n