.NET-Oberflächen mit Windows Forms oder WPF?

Seite 5: Zukunft und Fazit

Inhaltsverzeichnis

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.

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)