When creating a new GUI, is WPF the preferred choi

Question

Most restrictions and tricks with windows forms are common to most programmers. But since .NET 3.0 there is also WPF available, the Windows Presentation Foundation. It is said that you can make "sexy applications" more easy with it and with .NET 3.5 SP1 it got a good speed boost on execution.

But on the other side a lot of things are working different with WPF. I will not say it is more difficult but you have to learn "everything" from scratch.

My question: Is it worth to spend this extra time when you have to create a new GUI and there is no time pressure for the project?

Answer 1

WPF comes with many advantages such as superb data binding features, separation of concerns, separation of design and logic etc...

As a developer I enjoy the ability to define my UI using XAML as opposed to being tied to the Windows Forms designer and I feel good knowing I can count on another designer to make my app look good.

Personally I don't care older versions of Windows are not supported, but one of the big problems with WPF is that is is not (currently/ever) supported by Mono (http://www.mono-project.com) so WPF apps will not run on Mac OS or Linux. (Altough Silverlight applications will).

If you have the time and resources to invest in learning WPF, do it! Even if you're going to be writing Silverlight applications to support multiple OS's.

If you need desktop applications to run on multiple OS's stick with SWF.

Answer 2

If you decide to go with WPF, considering pros and cons already explained in the above answers, I highly recommend going through this dnrTV episode with Billy Hollis

Answer 3

The programming model for WPF is more open and flexible than Windows Forms is, but like ASP.NET MVC, it requires a little more discipline in terms of correctly implementing Model-View-ViewModel patterns.

My first LOB application with WPF ended up as an utter failuire, because it was a resource hog which brought my end-user's very-low-end laptops grinding to a halt... and this was ultimately because I just lept in with WPF + LINQ to SQL and expected a good result... and this is where WPF diverges so strongly from Windows Forms... In Windows Forms, you can get away with that sort of thing. WPF is much heavier on resources than Windows Forms, and if you don't architect your application to be lean, you end up with a 800-pound gorilla.

Don't shy away from WPF... explore it. But be aware that the acceptable sins of Windows Forms coding won't produce good results in WPF. They're fundamentally different engines, which lend themselves to fundamentally different coding patterns.

Last Word: If you do go ahead with WPF, get well acquianted with data virtualization for use with lists and grids. What is a simple data-bound ListItem or GridCell ends up being a hefty logical + visual object-graph in WPF, and if you don't learn how to virtualize, you application won't perform well on large data sets.

Answer 4

We are currently rewriting our application in WPF from Windows Forms. Yes, there is a steep learning curve and you have to "re-learn" some things, but it is so worth it. And combined with WCF, we are finding we are writing less code, faster, and more robust than ever before.

Stick with it for a while, read Adam Nathan's book, and check out the ever growing library of third-party controls like those from Telerik and ComponentOne. One negative, in my view, is that the design tool, Expression Blend, is very awkward to use. The latest version is still in beta, but it just doesn't feel right to those of us who have used Visual Studio for years. Yes, it's mainly for designers, but some things you just can't do in Visual Studio.

Answer 5

If you only care about supporting Windows and don't mind the time it takes to learn it, go with WPF. It's fast, flexible, easy to reskin, and has great tools to work with it.

Answer 6

A quote from an earlier post from Mark:

• In Windows Forms you design your user interface, then write code to drive that user interface, which generally also includes code to drive your data objects.
• In WPF you invest in the business layer that drives your data objects, then design an interface that listens to your data objects.

I would argue that this is more of a design choice, rather than whether or not you are using Windows Forms or WPF. However, I can appreciate that certain technologies might be better suited for a particular approach.