.NET-Oberflächen mit Windows Forms oder WPF?
Seit .NET 3.0 ist eine zentrale Frage bei der Entwicklung von .NET-Desktop-Anwendungen die Entscheidung zwischen der "alten" Windows Forms-Bibliothek und der neuen Windows Presentation Foundation (WPF).
- Dr. Holger Schwichtenberg
- Christian Kirsch
Seit .NET 3.0 ist eine zentrale Frage bei der Entwicklung von .NET-Desktop-Anwendungen die Entscheidung zwischen der "alten" Windows Forms-Bibliothek und der neuen Windows Presentation Foundation (WPF). Dabei entscheiden sich viele Unternehmen auch heute immer noch bewusst für Windows Forms, denn WPF birgt einige Herausforderungen.
10 wichtige Fragen zu .NET
In dieser zehnteiligen Serie liefert .NET-Experte Holger Schwichtenberg Antworten auf die am häufigsten gestellten Fragen, die .NET-Entwickler beschäftigen.
Während Java-Entwickler schon lange die Qual der Wahl zwischen verschiedenen Oberflächenbibliotheken (zum Beispiel AWT, SWT, Swing) haben, war die Welt für .NET-Entwickler in .NET 1.0 und 2.0 sehr einfach: Windows-Desktop-Anwendungen entwickelt man mit Windows Forms! Die waren zwar nicht identisch mit den in dem Zeitalter vor .NET verwendeten Microsoft Foundation Classes (MFC) für C++ und den VB Forms im klassischen Visual Basic, aber konzeptionell sehr ähnlich.
Mit WPF kam Bewegung auf den Desktop
Mit der Windows Presentation Foundation (WPF, früherer Codename "Avalon") hat Microsoft dann ab .NET 3.0 eine alternative Bibliothek eingebaut, die nicht nur Oberflächen für Windows-Anwendungen bereitstellt. WPF unterstützt verschiedene Arten von Benutzeroberflächen in einer durchgängigen Bibliothek, insbesondere:
- klassische Windows-Desktop-Fenster
- 2-D-Grafiken (vgl. GDI)
- 3-D-Grafiken (vgl. DirectX)
- Dokumente (vgl. Postscript und PDF)
- Browser-Anwendungen (vgl. Macromedia Flash und Java Applets)
- Animationen und Videos
WPF bietet nicht nur mehr Anwendungsarten, sondern viel reichhaltigere Visualisierungsmöglichkeiten. Dazu gehören Farbübergänge, Verformungen (Transformationen), Bildveränderungen (engl. "Pixel Shader") wie Schatten- und Spiegeleffekte, Überblendeffekte und Bewegungen (Animationen). So kann WPF jedes in jedem beliebigen Winkel kippen oder rotieren. Elemente lassen sich beliebig kombinieren, zum Beispiel kann ein Kontrollkästchen Teil eines Auswahlfeldes sein oder ein Video Hintergrund für eine Eingabefeld. Die Anzeige in WPF ist vektorbasiert und bietet daher eine gute Darstellung, unabhängig von der Größe des Anzeigegeräts, auch bei sehr kleinen Bildschirmen.
Durch die Definition wiederverwendbarer Formatvorlagen (Styles) lassen sich einheitliche Gestaltungsmerkmale auf Steuerelemente anwenden, denn Aussehen und Verhalten sind bei den Steuerelementen klar getrennt. Durch den Austausch der Formatvorlagen sind schnell gestalterische Anpassungen möglich – wie man es von Cascading Style Sheets im Web kennt. WPF bietet gegenüber Windows Forms ein wesentlich ausgeprägteres Ereignissystem und eine Abstraktion bei der Bindung von Oberflächenelementen an Befehle, durch das im aktuellen Kontext nicht verfügbare Elemente sofort ausgeblendet werden.
Code und Layout getrennt
Trennung von Layout und Code durch XAML
Anders als bei Windows Forms kann bei WPF die Beschreibung der Oberfläche durch XML-Elemente erfolgen. Microsoft hat dafür eine XML-Sprache namens Extensible Application Markup Language (XAML) entwickelt. In XAML sind einzelne .NET-Objekte und ganze Objektbäume beschreibbar. Zwar kann man in WPF eine Benutzeroberfläche auch noch in Form von Programmcode erstellen, dies ist aber nicht der bevorzugte Weg, denn XAML vereinfacht die Trennung von Code und Gestaltung.
In Windows Forms wurde die Benutzeroberfläche durch Code beschrieben, der, obwohl in einer eigenen "Designer-Datei" getrennt, eng mit dem Programmcode verzahnt war. In WPF kann man durch XAML viele Dinge deklarativ ausdrücken (beispielsweise Datenbindung, Animationen), die in Windows Forms gar nicht in der Designer-Datei untergebracht werden konnten. Für Windows Forms gab es als einziges Gestaltungswerkzeug den in Visual Studio eingebauten Designer. Für WPF existieren eigene Produkte für die Oberflächengestalter, z.B. Microsoft Expression Blend. Dadurch können Benutzeroberflächen einfacher von ausgebildeten Gestaltern erstellt werden. Bisher übernehmen diese Arbeit oft Softwareentwickler, denen Kenntnisse von Ästhetik und Benutzerfreundlichkeit fehlen.
WPF-Oberflächen laufen – genau wie Windows Forms – als eigenständige Windows-Fenster oder im Fenster eines Webbrowsers als sogenannte Web Browser Application (WBA). Sowohl WPF als auch Windows Forms erfordern jedoch beim Einsatz im Web ein vollständiges .NET Framework – zumindest das .NET Framework Client Profile – auf jedem Zielsystem. WBAs sind daher ebenso wie Windows Forms in der Praxis kaum im Browser zu finden, allenfalls in Intranet-Szenarien. Speziell für den Web-Einsatz hat Microsoft daher Silverlight entwickelt, ein Mini-.NET Framework mit einer abgespeckten und syntaktisch veränderten Version von XAML. Silverlight läuft als Browser-Plug-In mit "nur" 4,5 MByte Download (gegenüber mehr als rund 60 MByte für ein vollständiges .NET Framework bzw. 28 MByte für das .NET Client Profile, siehe Downloadgrößen). Bei der Verbreitung von Desktop-Anwendungen unterstützt WPF genau wie Windows Forms alle Möglichkeiten aus .NET, also XCopy-Deployment, Click-Once-Deployment oder MSI-Pakete.
Vor- und Nachteile
Viel Licht und viel Schatten
Bei so viel Licht ist auch ein großer Schatten nicht weit. Das erste K.O.-Kriterium ist für viele Softwareentwickler die Betriebssystemanforderung, da WPF nur ab Windows XP läuft. Wer noch Windows 2000 oder gar Windows 98/ME unterstützen muss, kann sofort aufhören, sich mit WPF zu beschäftigen. Das Framework braucht bei Hardware unbedingt eine moderne Grafikkarte mit Unterstützung ab Direct3D 9. Außerdem sollte man deutlich mehr RAM haben als Microsoft in den Mindestanforderungen des jeweiligen Betriebssystems angibt. WPF läuft auf jeden Fall in Leistungsprobleme, wenn man viele Elemente in einer Oberfläche verwendet, selbst wenn diese gerade gar nicht sichtbar sind. Während in Windows Forms die Anzeige von ein paar Hunderttausend Datensätzen in einer Tabelle mit jeweils nur 20 sichtbaren Zeilen kein Problem ist, macht WPF dabei schnell schlapp.
Der RAM-Hunger verursacht gerade beim Einsatz in Terminal Services Probleme. Auch belasten die grafischen Effekte von WPF das Netz deutlich mehr, was sich an einem Beispiel verdeutlichen lässt: Ein Farbverlauf lässt sich bei der Übertragung so optimieren wie eine einfarbige Fläche. Erst in Windows 7 in Verbindung mit einem Terminal Server auf Basis von Windows Server 2008 Release 2 gibt es eine Optimierung für die Übertragung der WPF-Effekte, bei der die Grafikkarte des Clients stärker zur Mithilfe herangezogen wird.
Kritik fordert WPF auch hinsichtlich der verfügbaren Steuerelemente heraus. Es besitzt weder in .NET 3.0 noch in .NET 3.5 Steuerelemente zur Darstellung von Daten in Tabellen (Datagrid) oder ein Auswahlfeld für Datum/Uhrzeit (Date-Time-Picker). Sie musste man entweder selbst entwickeln oder von Drittanbietern hinzukaufen. Erst seit Oktober 2008 bietet Microsoft auf seinem Quellcodeportal Codeplex solche Steuerelemente als Zusatz an (WPF Toolkit). Dass es dazu in den ersten zwei Jahren nach dem Erscheinen von WPF überhaupt keine Lösung von Microsoft gab, zeigt deutlich, dass der Hersteller bei der Entwicklung von WPF die typischen Geschäftsanwendungen völlig vernachlässigt hat.
Nur wenige WPF-Tools
Schlechte Werkzeugunterstützung
Katastrophal war und ist auch die Werkzeugunterstützung. Mit dem Erscheinen von .NET 3.0 im November 2006 gab es keinen grafischen Designer für WPF in Visual Studio, sondern nur eine Alpha-Version. Der Designer erschien erst mit Visual Studio 2008 und hat trotz erheblicher Nachbesserungen in dem Service Pack 1 immer noch zahlreiche eklatante Schwächen. So fehlt Unterstützung für Animationen und Datenbindung. Das aus Windows Forms bekannte Drag&Drop von Daten aus dem Datenquellenfenster und die Auswahl von Daten aus den Datenquellen gibt es hier nicht. Der WPF-Designer bietet keine Unterstützung für Lokalisierung, anders als der Windows Forms-Designer, bei dem man elegant zwischen den Sprachen umschalten kann. Die Darstellung im WPF-Designer entspricht oft nicht dem Resultat zur Ausführungszeit. Beim Einsatz des Viewbox-Steuerelements, der Grundlage für nahtlos skalierbare Fenster, gibt der Designer ganz auf. Erst mit Visual Studio 2010 ist Anfang des kommenden Jahres, also mehr als vier Jahre nach dem Erscheinen von WPF ein adäquater Designer zu erwarten.
In der Zwischenzeit verweist Microsoft stets auf Expression Blend. Es unterstützt zwar alle Funktionen von WPF und bietet das gleiche Projektformat wie Visual Studio, sodass eine gemeinsame Bearbeitung eines Projekts mit Expression Blend und Visual Studio möglich ist. Aber es gibt zwei Dinge, die Entwickler von Expression Blend abschrecken: Erstens kostet es zusätzliche Lizenzgebühren, zweitens ist die Bedienung an Grafik-Produkten wie Adobe Photoshop orientiert. Ein typischer Softwareentwickler, der Steuerelemente platzieren und mit Datenquellen verbinden möchte, muss eine völlig neue Welt lernen.
Hier ist man dann auch direkt an einem zentralen Punkt angekommen. WPF ermöglicht nicht nur, dass ausgebildete Gestalter an den Oberflächen arbeiten, sondern WPF erzwingt diese neue Rolle geradezu. Dieser Zwang entsteht einerseits durch die Werkzeugsituation und andererseits durch die Möglichkeiten, die WPF bietet. Nicht jedes Projekt hat aber die Ressourcen, einen Gestalter einzusetzen. Dies ist nicht nur eine finanzielle Frage, sondern es fehlen am Markt schlicht Gestalter, die WPF beherrschen. Dabei ist die Einarbeitung in WPF sowohl für Entwickler als auch Gestalter hartes Brot oder anders gesagt: Die Lernkurve ist sehr steil.
Zukunft und Fazit
Zukunft
Windows Forms ist in den aktuellen 3.x-Versionen von .NET enthalten. Es wird Teil von .NET 4.0 sein und – so betont Microsoft immer wieder – auch längere Zeit noch von .NET und den jeweils aktuellen Windows-Betriebssystemen unterstützt werden. Diese Kompatibilität ist Microsoft den .NET-Softwareentwicklern auch schuldig. Aber es wird kaum noch neue Funktionen für Windows Forms geben. .NET 3.5 und Visual Studio 2008 Service Pack 1 hat durch das .NET Framework Client Profile die Verbreitung von Windows-Forms-Anwendungen vereinfacht, die Startzeit verkürzt und fünf Steuerelemente, die es bisher nur als kostenlose Erweiterung gab, direkt mitgeliefert. Aber viel wird es da nicht mehr geben. "Neue Funktionen werden wir nur opportunistisch integrieren, da wir denken, dass Windows Forms bereits eine sehr ausgereifte Plattform ist", sagte Jason Zander, General Manager für das Visual Studio-Team in der Developer Division bei Microsoft, der iX im November letzten Jahres in einem Interview.
In WPF und insbesondere den kleinen Bruder Silverlight investiert Microsoft fleißig. Am 10. Juli 2009 ist Silverlight schon in Version 3.0 erschienen. Die Oberflächen von Visual Studio 2010 und des neuen Testwerkzeugs "Camano" basieren beide auf WPF. In .NET 4.0 erscheint die vierte Version von WPF (nach .NET 3.0, 3.5 und 3.5 SP1), die dann auch "kompatibler" zu Silverlight sein soll.
Die Windows Forms sind aber nicht leblos, was man auch an dem regen Drittanbietermarkt sieht. Firmen wie Telerik, Infragistics und Developer Express bieten inzwischen für Windows Forms einige der Konzepte (zum Beispiel Formatvorlagen) und Effekte aus WPF auch für Windows Forms in Ihren Steuerelementbibliotheken. Einmal mehr decken Drittanbieter den Bedarf, den Microsoft unbeachtet lässt.
Fazit
Die Wahl zwischen Windows Forms und WPF ist nicht einfach und nicht pauschal zu treffen. WPF bietet eindeutig mehr Funktionen, aber aus den dargestellten Gründen ist die Produktivität viel schlechter als in Windows Forms – und damit der Aufwand größer. Nach den Erfahrungen des Autors aus eigenen und fremden .NET-Projekten kann der Aufwand für eine WPF-Oberfläche leicht zwei- bis dreimal so hoch sein wie für eine mit Windows Forms erstellte.
Wer Zeit und Geld für WPF nicht hat, sollte also die Finger davon lassen. Tatsächlich ist Ergebnis vieler Beratungsprojekte, doch lieber auf das bewährte Windows Forms zu setzen, statt sich auf die vielen Herausforderungen von WPF einzulassen. Gerade Unternehmen, die typische Geschäftsprozessanwendungen entwickeln, schrecken (mit Recht) oft vor WPF zurück. Jason Zander brachte im Interview noch einen Aspekt ein: "Wenn man eine große Codebasis in Windows Forms hat, sollte man dabei bleiben." Ein Migrationswerkzeug von Windows Forms zu WPF gibt es nämlich nicht.
Wer heute noch bewusst auf Windows Forms setzt, macht nichts falsch. Das sagt sogar Jason Zander: "Ich würde aber nicht sagen, dass man auf jeden Fall WPF einsetzen sollte. Das ist eine Einzelfallentscheidung." Wenn man Microsoft glauben kann, werden Windows Forms-Anwendungen noch lange zuverlässig auf den Windows-Betriebssystemen laufen. Wer später doch Funktionen braucht, die nur WPF bietet, kann auch partiell umsteigen. In einer .NET-Anwendung lassen sich Windows Forms- und WPF-Fenster kombinieren, sogar innerhalb eines Fensters kann man – mit gewissen Einschränkungen – Steuerelemente der beiden Welten verbinden.
Dr. Holger Schwichtenberg
bietet mit seinem Unternehmen IT-Visions.de Beratung und Schulungen im .NET-Umfeld. Er hält Vorträge auf Fachkonferenzen und ist Autor zahlreicher Fachbücher.
(ck)
