ich suche noch nach einem wirklich guten Grund um von WindowsForms auf WPF umzusteigen.
Ich war lange der Meinung, dass ich WPF-Anwendungen relativ problemlos nach Silverlight transformieren könnte um somit auch gleich eine Weblösung zu haben. Aber dem scheint ja nicht wirklch so zu sein.
Trennung zwischen Layout und Code ist in WPF (MMVM-Pattern( besser gelöst als WindowsForms. Aber auch in WindowsForms kann ich Oberfläche von Logik trennen.
WPF wird zwar auch in Windows 8 unterstützt werden. Aber hat WPF langristig wirklich eine Zukunft?
Warum also WPF?
Ich freue mich auf eure Gründe! Vor allem WPF <--> Silverlight-Transformation interessiert mich :-)
Die Frage wäre in der Lounge vielleicht besser aufgehoben: http://codekicker.de/lounge, da sie m.E. eher auf einer Diskussion als auf eine Lösung abzielt.
WindowsForms wird seit 2005 nicht mehr weiterentwickelt. Es ist eine tote Technologie. Wenn man geschickt vorgeht, kann man sehr wohl eine WPF und Silverlight Anwendung parallel entwickeln. Ich habe hier bereits etwas dazu geschrieben. WPF, Silverlight, Windows Phone 7 und zukünftig WinRT bauen alle auf XAML auf. Insofern kommst Du auch nicht um diese Technologie herum, es sei denn Du überspringst alles und gehst direkt zu HTML5/JavaScript.
Wenn man einmal das Prinzip hinter XAML verstanden hat (Binding und all die Hilfskonzepte, um MVVM durchzuziehen), dann kann man zukünftig auf vielen Devices parallel entwickeln.
Weil die Frage grad nochmal wieder hochgepoppt ist: die letzten neuen Features für Windows Forms gab es Ende 2007, nicht 2005, mit .NET 3.0: http://msdn.microsoft.com/en-us/library/bb762963%28v=vs.90%29.aspx Bugfixes und Anpassungen an neue Windows-Versionen gab es auch noch in den Folge-Releases. Richtig "tot" ist Windows Forms also nicht. "feature complete" und "in maintenance mode" trifft es aus meiner Sicht besser.
Naja, wann ist eine Technolgie tot? Vielleicht ist der Begriff 'legacy' besser: Der Lebenszyklus der Technologie geht zu Ende. Auch mit VB6 läßt sich noch Software für Windows 8 entwickeln, aber ist es sinnvoll? Es steht ja im Moment selbst zu Diskussion, ob nicht auch WPF seinen Lebenszyklus beendet, da es kaum Neuerungen in letzter Zeit gibt-verglichen zB mit ASP.NET MVC. WinForms, Silverlight, WP7, IMO auch WP8 (weil es wohl mit Win Blue mit WinRT zusammen läuft) sind garantiert legacy. Ob XAML/C# sich gegen HTML5/JS behaupten kann, wird sich wohl erst in den nächsten 1-2 Jahren zeigen.
Ich habe auch lange überlegt, ob wir unsere Windows-Forms-Anwendungen auf WPF migrieren sollten. Letztendlich ist es der wankelhaften Strategie von Microsoft zu verdanken, dass ich es nicht getan habe. Nachdem MS signalisiert hat, dass Silverlight nicht mehr wirklich weiterentwickelt wird (was ich sehr bedauere), haben sich die Prioritäten zugunsten HTML5/Javascript verschoben.
Ich muss auch ehrlich zugeben, dass die Art der Datenbindung in WPF/Silverlight für viele Entwickler (mich eingeschlossen) doch sehr ungewohnt ist/war und einiges an Eingewöhnungszeit kostet.
Um HTML5/JS kommt man zukünftig sicherlich nicht herum, aber es baut dann doch auf einem anderen Paradigma auf ("Webentwicklung erobert Desktop") und steht ganz am Anfang. Ich sehe JavaScript als Mittel zum Zweck. Eine schöne Sprache ist es nicht. Und ja, Microsoft hat bei WPF/Silverlight/XAML-WinRT das Prinzip MVVM nicht zu Ende gedacht und implementiert. So bleibt es dem Entwickler mit Zusatzaufwand und viel Einarbeitung überlassen, eine saubere Anwendung zu entwickeln. Der Schwerpunkt liegt zu sehr auf dem Marketing - man sieht es am 'Rückschritt' zu JavaScript
Imho wollen die Kunden zu 90% Webanwendungen haben. Nur in wenigten Fällen, wo z.B. externe Geräte, Messinstrumente etc. angebunden werden, programmieren wir noch Desktop-Anwendungen mit Windows-Forms.
Als Maßregel empfehlen wir jedem Kunden ab 5-10 Clients auf Desktopanwendungen zu verzichten, da der Wartungsaufwand einfach zu hoch ist.
Von daher ist HTML5/Javascript mMn kein "Mittel zum Zweck" sondern ein Muss. Javascript ist vielleict keine schöne Sprache, dafür aber (für viele Programmierer) einfacher zu erlernen als WPF.
Ich würde sagen, das hängt vom Kundenkreis ab. Bei unseren kann ich mir das nicht vorstellen bzw. allein für uns intern schon nicht. Vielleicht liegt's am Design aber Webanwendungen verbinde ich immer mit Klicken und weniger mit Hotkeys und guter Tasturnavigation.
Kunden mit mehr Clients können auch problemlos auf TFS oder andere Lösungen umsteigen, dann reduziert sich auch der Wartungsaufwand, zumal es ja doch noch mehr Software auf dem Rechner gibt, als nur DIE Fachanwendung. Und Google-Docs in der Cloud ist nicht jedermanns Sache. Trotzdem ist die Frage über die Zukunft natürlich da.
Nur mal als Interessensfrage: Kann der Team-Foundation-Server (v.a. die Express-Version) automatisch Releases verteilen, wenn die Anwender keine Admin-Rechte haben?
Für Intranets innerhalb von Firmen sehe ich Silverlight als ideale Lösung: Schnell, SSO, einfach zu deployen. Wenn man direkt auf Controls wie z.B. Telerik setzt, muss man sich auch nicht sehr um das Design kümmern. Mit dem Einsatz von PRISM hat man auch Muster Templates für den modularen Aufbau mit MVVM. Es muss sich nur eine Person mit der Achitektur auskennen. Die anderen können an den ViewModels, Services und Backend entwickeln ohne wissen zu müssen, wie das genau mit MVVM funzt. Silverlight wird offiziell auf jeden Fall bis 2021 unterstützt. Da ist man fast sicherer als mit HTML5/JS.
@Jens Meintest Du in Deinem ersten Kommentar mit "TFS" wirklich den Team Foundation Server? Wenn ja: wie war das gemeint? Oder hattest Du eher an Windows Terminal Services gedacht?
@Jens "silverlight 2021" googeln: http://support.microsoft.com/gp/lifean45#sl5 Kleine Hintertür in der Formulierung: wenn die derzeit unterstützten Browser/OS-Kombis vorher aus dem Support laufen, denn neue Versionen werden "nach Bedarf" hinzugefügt. WPF gilt als Teil von .NET, also (seit 3.5SP1) als Teil des Betriebssystems und unterliegt somit den Windows-Support-Zyklen: http://support.microsoft.com/lifecycle/?p1=14380
@Jens: hatte ich mir doch gedacht ;-) @mblaess: Der TFS ist hier nur durch einen Tipp-Fehler in die Diskussion mit hineingeraten. Vielleicht machst Du für Deine Frage lieber einen neuen Thread auf?
