{"id":3016,"date":"2012-08-31T17:21:37","date_gmt":"2012-08-31T15:21:37","guid":{"rendered":"http:\/\/www.centigrade.de\/blog\/en\/?p=3016"},"modified":"2021-01-07T15:22:21","modified_gmt":"2021-01-07T14:22:21","slug":"einstieg-in-wpf-erlebnisse-eines-ehemaligen-windows-forms-entwicklers","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/einstieg-in-wpf-erlebnisse-eines-ehemaligen-windows-forms-entwicklers\/","title":{"rendered":"Einstieg in WPF \u2013 Erlebnisse eines ehemaligen Windows Forms Entwicklers"},"content":{"rendered":"

Haben Sie schon einmal ernsthaft daran gedacht, von Windows Forms (WinForms) auf WPF umzusteigen? Die neue Anwendung nicht mehr nach altbekanntem Muster schreiben sondern etwas Neues zu wagen? Um ehrlich zu sein, bis vor ein paar Monaten habe ich mir keine Gedanken bzgl. eines Umstiegs gemacht. So wohl vertraut ist mir die Windows Forms Welt. Darin kenne ich mich aus, WPF m\u00fcsste ich neu erlernen. Also blieb es bei einem Testprojekt und meine Anwendungen blieben weiter in Windows Forms. Als ich dann Anfang dieses Jahres nach fast 15 Jahren als Entwickler in der Finanzbranche zu Centigrade gekommen bin, war hier der Umstieg l\u00e4ngst vollzogen. Werfen Sie mal einen Blick in unsere Blog-Artikel zu diesem Thema! Meine Kollegen im Bereich Design Engineering<\/a> arbeiten schon seit einigen Jahren mit WPF. Insbesondere die j\u00fcngeren Designer und Design Engineers kannten Windows Forms gar nicht aus der Praxis, sondern \u2013 wenn \u00fcberhaupt \u2013 nur aus dem Studium. Viele Unternehmen setzen WPF ein, aber trotz der bereits vierten Version der Technologie befinden sich noch einige von ihnen in der Einf\u00fchrungsphase. Aber aus eigener Erfahrung kann ich nur berichten \u2013 das ist nicht \u00fcberall so. Gerade in der Finanzbranche werden weiterhin eher trist wirkende Anwendungen in Windows Forms gebaut. Dabei geht es doch auch ansprechender\u2026<\/p>\n

So begann f\u00fcr mich ein neues Kapitel in meiner Programmiererlaufbahn. Mit einer gesunden Portion Skepsis bin ich in mein erstes WPF Projekt eingestiegen \u2013 und ich war sofort begeistert. Einige meiner Erfahrungen habe ich gesammelt und in diesem Artikel zusammengefasst.<\/p>\n

Formulardesign in Expression Blend \u2013 Wie style ich meine WPF-Anwendung?<\/h2>\n

Wer kennt ihn nicht, den guten alten Formulardesigner f\u00fcr Windows Forms. Element aus der Toolbox ausw\u00e4hlen, auf den Workspace ziehen, Gr\u00f6\u00dfe und Text anpassen und schon ist sie fertig, meine Control. Ging doch schnell, sieht aber irgendwie ziemlich nach Standard aus. Mit den Bordmitteln ist hier nicht viel rauszuholen. Button bleibt Button, Checkbox bleibt Checkbox. Das hat mich 1997 beim Einstieg in Visual Basic 5.0 sehr angesprochen. Alle bisher verwendeten Programmiersprachen (Pascal, Cobol) hatten keine graphische Oberfl\u00e4che sondern nutzten f\u00fcr Ein- und Ausgabe ausschlie\u00dflich die Konsole. Heute l\u00f6st Windows Forms jedoch keinen Begeisterungssturm mehr aus. Die optischen Verbesserungen seit Einf\u00fchrung von Windows Forms sind recht \u00fcberschaubar. Gibt es da nichts Neues?<\/p>\n

Auf den ersten Blick bin ich ein wenig ern\u00fcchtert bei meinen ersten Kontakten mit WPF, der Designer in Visual Studio verh\u00e4lt sich in dieser Technologie fast gleich. Ich ziehe einen RadioButton aus der Toolbox und es erscheint eine Windows Standard Control. War das wirklich schon alles? Mein Kollege gibt mir einen Tipp: Schlie\u00dfe dein Projekt und \u00f6ffne es neu im eigentlichen WPF Designer Werkzeug \u2013 Expression Blend. Ein paar Klicks und schon bin ich im Template, also dem Bauplan, meines RadioButton angelangt. Mein Kollege zeigt mir, welche \u00c4nderungen es ben\u00f6tigt, um aus einem langweiligen einen ansprechenden RadioButton zu stylen. Den urspr\u00fcnglichen RadioButton haben wir innerhalb k\u00fcrzester Zeit in seine Einzelteile zerlegt und ihn aus v\u00f6llig anderen Bestandteilen neu aufgebaut. Ein Farbverlauf hier, ein Schatten-Effekt da. Wir realisieren noch schnell die States und schon ist er nicht mehr wieder zu erkennen. W\u00e4hrend wir den Style des RadioButton ver\u00e4ndern, sehe ich, wie der Xaml-Editor flei\u00dfig Code generiert.<\/p>\n

\"\"<\/a><\/p>\n

A: Standard WPF Style, B: Custom Style, C: Windows 8 Style UI<\/p>\n

Xaml \u2013 Design per Code leichtgemacht<\/h2>\n

Das also ist Xaml<\/a>-Code. Ich bin etwas ratlos und frage meinen Kollegen: \u201eEnth\u00e4lt dieser Xaml-Code tats\u00e4chlich alle \u00c4nderungen, die wir gerade per Designer durchgef\u00fchrt haben? Kann ich also meinen kompletten Button auch stylen, in dem ich Zeile f\u00fcr Zeile Xaml schreibe?\u201c Als Antwort erhalte ich ein: \u201eJa, klar! Aber noch viel besser, du kannst den Style und das Template f\u00fcr deinen Button auch auslagern und ihn auch einer anderen Button-Instanz zuweisen. Daf\u00fcr gibt es das ResourceDictionary.\u201c Mein Kollege zeigt mir, wie man Template und Style einer Control in dieses Dictionary auslagert. In den verschiedenen Dictionaries liegen bereits allerlei andere Styles, Farben, Brushes, etc. Alles ausgelagert \u2013 per Key kann ich jederzeit auf eine dieser Ressourcen zugreifen. Das will ich nat\u00fcrlich ausprobieren. Ich verweise in meinem Xaml einfach auf das Dictionary und w\u00e4hle f\u00fcr meinen Button einfach einen anderen Style. Und schon sieht er wieder vollkommen anders aus.<\/p>\n

Designen ohne Programmierkenntnisse \u2013 Wirklich?<\/h2>\n

Wir arbeiten weiter und stylen das Layout unserer Benutzeroberfl\u00e4che. Bisher haben wir noch keine Zeile C# Code geschrieben. \u201eLangweilig!\u201c \u2013 sagt mir ein erster Entwicklerreflex. Aber toll ist es irgendwie trotzdem. Als reiner Entwickler kann ich mich in Zukunft ausschlie\u00dflich auf die Realisierung der Programmlogik konzentrieren. Die Interaktion mit der Pr\u00e4sentationsschicht betrifft mich nur noch sekund\u00e4r.<\/p>\n

\u201eDie Programmlogik ist bereits in Teilen vorhanden\u201c, sagt mein Kollege. \u201eSie kommt von unserem Auftraggeber. Wir nehmen darauf keinen Einfluss.\u201c Per Bindings verbinden wir ausschlie\u00dflich unsere Oberfl\u00e4che mit dem darunterliegenden Programmcode. Da leuchten zum ersten Mal so richtig meine Augen! Eine echte Trennung von Pr\u00e4sentationsschicht und -logik. Ich kann also nach meinen Vorgaben die Oberfl\u00e4che von einem Designer erstellen lassen und h\u00e4nge sie einfach so an meine Anwendung? Das ist fast so sch\u00f6n um wahr zu sein. Und doch geht es. Ich kann meine komplette Anwendung umgestalten lassen. Und das ohne eine einzige Zeile C# Code. Aber wie geht das?<\/p>\n

MVVM \u2013 Kooperation zwischen Designer und Entwickler<\/h2>\n

Die L\u00f6sung lautet MVVM (Model View ViewModel)<\/a>. Diese Architektur erlaubt die komplette Trennung von Pr\u00e4sentationdarstellung und -logik. Die View besteht nun fast ausschlie\u00dflich aus Xaml-Code. Diese kann beliebig von einem Designer Engineer erzeugt und ver\u00e4ndert werden, selbst dann schon, wenn ihm das Model (die Programmlogik) noch gar nicht vollst\u00e4ndig vorliegt. Einzig und allein die Schnittstellen des ViewModels muss er kennen. Das ViewModel enth\u00e4lt die Interaktion beider Schichten. Ich habe zudem im Gegensatz zu Windows Forms die M\u00f6glichkeit des sog. \u201eTwoWay Bindings\u201c. Habe ich z.B. eine TextBox und m\u00f6chte deren Inhalt ver\u00e4ndern, bleibt mir nur die Zuweisung von Hand im Code. DataBindings gibt es zwar auch in Windows Forms, aber leider nur auf Datenquellenebene. Ein Binden an eine String Variable ist nicht m\u00f6glich. Das geht aber Dank der Bindings in WPF problemlos. Dank MVVM und den DataBindings synchronisieren sich nun TextBox und Variable in beide Richtungen. Diese Art und Weise der Bindings erm\u00f6glicht ein echtes Losl\u00f6sen des Layouts. Aus dem Code spreche ich nirgends eine Control direkt an, sondern kommuniziere ausschlie\u00dflich indirekt via Change-Events \u00fcber die im ViewModel angelegten Properties. Spaghetti Code mit kruder GUI Logik geh\u00f6rt damit der Vergangenheit an und ich kann das korrekte Verhalten des ViewModels sogar mit einem Unit-Test verifizieren. Aber geht das wirklich immer so einfach? Kann alles im View Layer per Designer und Xaml-Code gel\u00f6st werden?<\/p>\n

Behavior, Converter, Trigger \u2013 Erste Arbeit f\u00fcr Entwickler?<\/h2>\n

Nein, ganz so einfach ist es doch nicht. Zwischen View und ViewModel befindet sich noch eine Art Zwischenschicht mit Komponenten, die eher dem View-Layer zugerechnet werden. Diese Komponenten bilden sprichw\u00f6rtlich den Kleister zwischen den View und ViewModel Schicht. Nehmen wir als Beispiel eine einfache Berechnung zwischen zwei Zahlen. Im Formular befinden sich drei Textfelder, Feld 1 und 2 enthalten die zu berechnenden Werte, Feld 3 das Ergebnis. Im Xaml-Code ist diese Berechnung nicht so einfach durchzuf\u00fchren. Also brauchen wir an dieser Stelle einen sog. Converter, der im Xaml per Binding an alle drei Textfelder gebunden wird und somit bei jeder \u00c4nderung der Eingabewerte eine neue Berechnung ausf\u00fchrt. Gerade einfache Berechnungen oder Konvertierungen geh\u00f6ren nicht in die Programmlogik sondern werden als Converter ausgelagert. Und an dieser Stelle darf endlich programmiert werden! Hier ist der Engineer im Design Engineer gefragt und weniger der Designer. Neben Convertern gibt es auch noch sog. Behaviors und Trigger\u2026 diese aber zu erkl\u00e4ren w\u00fcrde den Rahmen sprengen. Ich kann nur sagen \u2013 sie vereinfachen die Zusammenarbeit zwischen Entwicklern und Designern nochmals um ein vielfaches.<\/p>\n

Effekte und PixelShader \u2013 Ausnutzen der Hardwarebeschleunigung<\/h2>\n

Genau so sieht es mit dem Thema \u201evisuelle Effekte\u201c aus. Stellen Sie sich vor, sie m\u00f6chten einen \u201eGlow\u201c-Effekt realisieren, wenn Sie einen Button anklicken. Dieser Effekt soll nat\u00fcrlich \u00fcber allen anderen Controls leuchten, die in direkter Umgebung liegen. Dazu w\u00e4re es sch\u00f6n, wenn der Effekt nicht einfach ein halb durchsichtiges Rechteck mit einem Farbverlauf in seinem Inneren ist, sondern ein richtig sch\u00f6nes Gl\u00fchen (wie z.B. in Photoshop mit einem Blendmode) in der Form unserer Control als Silhouette zu sehen ist.<\/p>\n

\"\"<\/a><\/p>\n

Hier wird ein Derivat der WPF Effect-Klasse ben\u00f6tigt \u2013 und damit auch wieder C# Code. Wir w\u00e4hlen also die Control, ziehen auf diese unseren Effect, w\u00e4hlen einen BlendMode und ein Objekt aus, welches die Farbe f\u00fcr unseren Effekt enth\u00e4lt. Im Effect selbst muss nun ein PixelShader angesteuert werden. Welchen Vorteil bietet uns das? \u201eNormale\u201c Effekte in WPF (z.B. der DropShadowEffect) sind meist recht umfangreich ausgestattet und damit nicht besonders performant. Gerade auf Industrie-PCs (wie in unserem Kundenkreis oft eingesetzt) muss eine einfache, schnelle L\u00f6sung her. Um den schon besprochenen BlendMode zu realisieren, integrieren wir daher einen PixelShader. Dieser enth\u00e4lt nur den eigentlichen Effekt ohne gro\u00dfe Einstellm\u00f6glichkeiten. PixelShader werden in HLSL<\/a> beispielsweise in dem gro\u00dfartigen Shazzam Editor<\/a> programmiert und arbeiten besonders performant, da sie direkt in der GPU der Grafikkarte gerendert werden. Das entlastet beim Rendern der Oberfl\u00e4che die CPU. Mittels eines Behaviors kann ich diesen Effekt jetzt auch noch \u00fcber die eigentliche Content-Schicht in WPF \u2013 n\u00e4mlich in den AdornerLayer \u2013 platzieren. Das ist wichtig, damit auch der Hintergrund Einfluss auf die Farbe des Gl\u00fchens hat. Dieses Schichtenmodell ist in dieser Form \u00fcbrigens nicht in Windows Forms enthalten \u2013 das Realisieren von Effekten leider auch nicht.<\/p>\n

Skalierbarkeit \u2013 Optimale Sicht in jeder Aufl\u00f6sung<\/h2>\n

Was uns zum n\u00e4chsten Punkt bringt: die Skalierbarkeit der Oberfl\u00e4che. Haben Sie mal versucht eine Windows Forms Anwendung zu skalieren? Sie k\u00f6nnen die Controls an den Screen binden und so deren Gr\u00f6\u00dfe dynamisch \u00e4ndern und sie alignieren \u2013 aber skalieren? W\u00e4hrend meiner Zeit als IT-Verantwortlicher habe ich so einige Merkw\u00fcrdigkeiten zu Gesicht bekommen. Eine ehemalige Kollegin hatte an ihrem 24\u201c LCD Display eine Aufl\u00f6sung von 800×600 Pixel eingestellt. Normal ist bei diesem Display eine Aufl\u00f6sung von 1680×1080. Auf die Frage, warum sie das so eingestellt hat, bekam ich die Antwort: \u201eWeil ansonsten alles so klein ist!\u201c Die Anwendung, in der sie haupts\u00e4chlich arbeitet, ist f\u00fcr eine Ausl\u00f6sung von 1024×768 Pixel konzipiert. Wenn man nun an einem so gro\u00dfen Display arbeitet und das Fenster der Anwendung gr\u00f6\u00dfer zieht, hat man nichts gewonnen. Alle Controls bleiben gleich gro\u00df. Ist das sch\u00f6ne, hochaufl\u00f6sende LCD Display damit hinf\u00e4llig? Nein, in WPF kann ich mein Layout so gestalten, dass ich seine Gr\u00f6\u00dfe individuell skalieren kann \u2013 nat\u00fcrlich ohne Qualit\u00e4tsverluste, da alles vektorbasiert gerendert wird. So sieht eine WPF-Anwendung auf allen m\u00f6glichen Screentypen und Pixeldichten immer gestochen scharf aus. Gerade auf Maschinenterminals, die meist recht unterschiedliche Aufl\u00f6sungen haben, ist das ein absolutes Muss.<\/p>\n

Touch-Bedienung \u2013 Am besten in WPF realisieren<\/h2>\n

Apropos Maschinenterminals \u2013 diese haben meist keine Eingabeger\u00e4te wie Maus oder Tastatur sondern werden im Regelfall per Touch bedient. Gerade bei komplexer Funktionalit\u00e4t sind Gesten mit einem oder mehreren Fingern unumg\u00e4nglich. Jeder, der heute ein Smartphone oder einen Tablet-Computer besitzt, kennt diese Gesten. Auch die Bedienung im bald erscheinenden Windows 8<\/a> ist daf\u00fcr ausgelegt. Haben Sie sich daher schon mit dem Thema Touch-Bedienung und komplexe Gesten in Windows Forms besch\u00e4ftigt? Nein? Lassen Sie es besser, die Implementierung der Touch-Bedienung in Windows Forms ist so gut wie nicht vorhanden. Mittels einer Ein-Finger-Geste Objekte anklicken l\u00e4sst sich noch problemlos darstellen. Alles, was dar\u00fcber hinausgeht, ist nicht oder nicht in vern\u00fcnftigem Rahmen zu realisieren. Machbar ist zwar bekanntlich (fast) alles, doch weshalb nimmt man nicht gleich die bordeigenen Mittel in WPF? Das geht deutlich einfacher und selbst komplexe Gesten lassen sich ohne allzu gro\u00dfen Aufwand realisieren.<\/p>\n

Datenanbindung \u2013 WPF und das Entity Framework<\/h2>\n

Bleibt noch eins meiner Lieblingsthemen \u2013 die Anbindung von Datenbanken. Ich habe lange Zeit mit Datenzugriffen \u00fcber DAO, ADO bzw. ADO.Net gearbeitet und das Entity Framework erst vor recht kurzer Zeit kennengelernt. Gerade bei Themen, in denen man sich mit seinem Wissen sicher f\u00fchlt, ist man Neuem gegen\u00fcber bekanntlich besonders kritisch. Aber auch hier gibt es nichts zu m\u00e4keln. Die Anbindung an WPF erfolgt wie in Windows Forms auch per Data-Binding. Bei Elementen, die mehrere Datens\u00e4tze enthalten k\u00f6nnen (z.B. ComboBox, Grid), wird als Datenquelle eine ObservableCollection hinterlegt, die sich automatisch aktualisiert und deren Inhalt somit immer den aktuellen Datenstand repr\u00e4sentiert. Der eigentliche Zugriff auf die Daten erfolgt ausschlie\u00dflich in der Programmlogik und damit nicht im Bereich des Designs. Das hat den riesigen Vorteil, dass sich der Design Engineer beim Konstruieren der Views \u00fcberhaupt nicht mit dem Thema Datenherkunft besch\u00e4ftigen muss. Der Designer kann in Expression Blend dank sog. Sampledaten sogar zur Designzeit, also nicht zur Laufzeit, mit Dummy Daten arbeiten und diese Stylen, bis diese dann schlie\u00dflich mit den echten Datenbankdaten ersetzt werden. Das sollte zwar auch f\u00fcr Windows Forms Anwendungen gelten, dort k\u00f6nnen jedoch die Data-Bindings nicht verwendet werden, wenn keine direkte Kommunikation zur Datenquelle stattfindet. Trotz besonders strengem Blick wollten mir auch hier keine Nachteile von WPF zu Windows Forms auffallen.<\/p>\n

Fazit \u2013 Was von Windows Forms \u00fcbrig blieb<\/h2>\n

Zugegeben, es ist nicht ganz einfach mit WPF. Ein bisschen Lernen und \u00dcben muss man schon. Insbesondere der Wechsel zwischen der festen Verdrahtung von Oberfl\u00e4che und Logik in Windows Forms hin zum MVVM-Pattern in WPF sorgt am Anfang f\u00fcr Schwierigkeiten. Hat man diese \u00fcberwunden und sich die Logik verinnerlicht, sprechen die Vorteile von WPF schnell f\u00fcr sich. Wirklich ernstzunehmende Vorteile bietet Windows Forms gegen\u00fcber WPF heutzutage nicht mehr. Die guten Ans\u00e4tze wurden in WPF \u00fcbernommen und deutlich verbessert. Dazu hat man neue Features in den Bereichen Grafik und Effekt realisiert. Wei\u00df man mit WPF umzugehen, ist auch die Performanzfrage nicht mehr so dramatisch<\/a>. F\u00fcr mich als Entwickler sind auf einen Schlag ungeahnte Welten bzgl. Design und Usability entstanden. Eine Anwendung kann jetzt neben ihrer (hoffentlich) tollen Funktionalit\u00e4t auch mit einer augenfreundlichen Oberfl\u00e4che und einer herausragenden Bedienbarkeit punkten. Und ganz unter uns, wer sehnt sich heute in Zeiten von Smartphone und Tablet- Computer noch an sein VT-100 Terminal zur\u00fcck\u2026<\/p>\n

Wenn Sie gerne mehr \u00fcber unsere Herangehensweise an Projekte und Services herausfinden m\u00f6chten, lesen Sie gerne auf unserer Engineering<\/a> Seite weiter.<\/p>\n

Ein Jahr sp\u00e4ter: N\u00fctzliche WPF Werkzeuge (nicht nur f\u00fcr ehemalige WinForms Entwickler)<\/h2>\n

Nach gut einem Jahr voller neuer Erfahrungen in WPF m\u00f6chte ich diesem Artikel ein kleines Update g\u00f6nnen und den Blick auf ein paar Werkzeuge lenken, die mir im Laufe des vergangenen Jahres die Arbeit mit WPF deutlich vereinfacht haben:<\/p>\n