Is WPF a good choice for developing line of business user interfaces?

Question

We're debating whether our future Windows UI development should be WinForms or WPF. How have some of you made this decision? Most of our applications are LOB applications, and I'm not sure I see a clear and overwhelming benefit to WPF for these types of applications. However, my knowledge of WPF is limited. I'm also a little concerned that WPF will be in vogue for another couple years and then Microsoft will get tired of it and push something else on us. I guess one argument against this is the fact that Visual Studio 2010 is a WPF application.

Thanks.

Answer 1

One thing to bear in mind is Silverlight. Is it possible that you'll want to write your application to be run from a browser in the future, or possibly even from a Windows Phone 7 device? While Silverlight and WPF aren't quite the same, they're extremely similar. This would be my primary "future-proofing" argument in favour of WPF.

Personally I like the composition model of WPF - as well as a declarative way of representing the UI, and a better layout system than WinForms. Not that I'm a UI guy, really.

Answer 2

WPF looks set to replace Winforms, at least on Windows Mobile devices, with future development focused around Silverlight (a WPF spinoff) and XNA.

In an open market, it makes sense to cover WPF if you want to keep yourself attractive to a wider recruitment market.

Answer 3

I've wondered that myself. But the fact that VS2010, like you said, makes a lot of use out of WPF says to me that Microsoft is trying to tell the world that it's not just another MS fad, but it's going to stay around for some time.

Answer 4

I think MS is sending a clear message that WPF and Silverlight are the present and future. The Winforms PM has said as much. Additionally, WPF and Silverlight are expected to converge in the future.

We went through this same dilemma about 6 months ago at my office. We were starting a large LOB app and no one on the team had a lot of experience in WPF or Winforms. That being the case, we couldn't find an overwhelming reason to go with Winforms and we felt that WPF offered us a much cleaner separation of concerns. We decided to go with WPF and use PRISM as the app framework. 6 months on, I think we made the right choice.

Answer 5

There are a lot of factors to consider here.

Reasons not to choose WPF:

• It currently has less support than WinForms for common LOB controls like date pickers, numeric entry widgets, and so on, though this is improving via the WPF Toolkit, in WPF 4 and through third party control vendors.
• The tooling isn't fit to kiss the Windows Forms designer's boots. (Though to be fair this is partly because the tooling has to cope with much more sophisticated ways of constructing views. And Blend is definitely getting there.)
• A very different mental model to Windows Forms. To get real benefits out of WPF, you need to think in a very different way to what you're used to. So there may be a substantial learning curve -- not just in terms of learning the technology, but in terms of internalising the idioms and patterns (though there are now a lot more community resources around idiomatic WPF than there used to be).

Reasons to choose WPF:

• Decent architectural support. WPF (if you do it right) has a decent separation of code and UI built in, making WPF applications much easier to test and to evolve.
• Greater flexibility. For example, if you need a simple map display, you can build it in a couple of hours from a ListBox, instead of having to research and purchase a third party component or write a map control from the ground up. Simple data visualisation is a killer feature for WPF.
• WinForms is a dead end. It's not going to see any enhancements from Microsoft, and control vendors are already beginning to shift to WPF as the WinForms market saturates.
• Most of your WPF experience can be ported to Silverlight, which (a) gives you flexibility to bring your apps to the browser and the phone, and (b) gives you additional confidence that Microsoft won't lose interest -- even if they do get "tired" of WPF, they've shown a very strong commitment to Silverlight.

Personally, if I were starting a Windows desktop app now, I would choose WPF. However, I've already climbed the learning curve. For a team that doesn't have WPF experience, the cost of taking it on must be a greater factor than it is for me.

Answer 6

Being that they essentially ditched winddows mobile for Windows Phone 7 which will only use WPF and XNA as its main UI layer I would have to say yes. One could even consider this move as an expiriment for the much more widely deployed Windows OS. That and most users love dumbed down eye candy IMHO.

Answer 7

Knowing both, I really hope that WPF is the future. Windows Forms has incredible pain points, e.g. regarding Data Binding, and it's pretty much a thin film of .NET on a lot of existing stuff. When I had to debug into classes like BindingSource, it scared the hell out of me. Now, I don't know how the WPF classes look inside, but Microsoft is bound to have learned something between 2001 and 2006.

I love WPF because of

• styling
• data templates
• excellent and first class data binding support
• declarative UI set-up
• atached properties
• ...

I can only hope that Microsoft will make more use internally of this UI technology, thereby reducing its weaknesses which have mostly to do with performance. WPF is fairly demanding. In VS2010 I hope to see designers that will show off the power of the UI (the XML Schema designer in the Beta already looked pretty useful). I would think that an App like MS Word would profit a lot from all the transformation capabilities of WPF.

Answer 8

WPF is a game-changer for me. My company's flagship application is a WinForms program whose UI is build dynamically at runtime from metadata. It was about six months' effort, all told, to get the UI even stable, let alone attractive. There are still some bugs that I haven't been able to fix, largely because UI code is hopelessly and unavoidably intertwined with data-model code. And don't get me started on window handles.

Now that the system's been in production for a year or so, customers are coming to me with requests like, "We'd like to be able to reorder the information on this screen by dragging and dropping," and "Can we get this information to display in a grid on this part of this tab?" and - my favorite - "Can we get spell-check and auto-text?" Those requests go onto a backlog that's getting pretty damn long.

It's taken me a fair amount of time to figure out how to refactor the application's design so that it can support a WPF UI. (Actually, that's a considerable understatement. I've been grappling with this off and on for a year and a half, and I only started getting traction on it once I broke out of the WPF books I was working from and learned MVVM.) Once I did, the results are spectacular.

The code is much simpler. There's much less logic to debug. Everything in the UI is much faster, which is important because the whole reason this is a desktop app in the first place is that we needed a very responsive UI. My program can create thousands of UI controls without my having to worry about window handles. The ease with which I'm able to change the look and feel of the program is jaw-dropping.

(An example: The UI presents DataRows with a variety of templates. Since a given screen can have dozens of rows on it, and the cursor is kind of small, it's useful for the user to be able to tell, at a glance, what row the cursor is in. It took me ten minutes to implement the styles that now make this visual affordance available everywhere in my application. That's less time than it would take me to estimate that feature if I wanted to add it to my WinForms app. Granted, it would have taken a lot longer if it couldn't be done by adding two styles. WPF's is seriously not magic.)

Are there downsides? As Ms. Palin likes to say, you betcha. Browse some of the questions I've asked on SO - the one about how a no-op value converter changed the behavior of data binding is a good one. The entire rub-your-belly-while-patting-your-head approach to debugging bindings is pretty frustrating, especially since it's so easy to have binding errors and not even know it. (I now keep my Output window on the screen at all times just so that if there are any binding errors while I'm testing, the movement of the messages getting logged will catch my eye.) It would be nice to be able to get a real stack trace when your window throws a XamlParseException. Don't start me talking, I could talk all night.

And the tools! Visual Studio's visual tools for building WPF UIs is completely useless to me. I have Blend, and have used it to re-template a control, but in general I find using Blend to be like trying to jog through a swamp full of hubcaps and baling wire. I'm sure it's really awesome if all you know is Blend, but if what you learned first is the WPF object model and XAML, the behavior of Blend is pretty mysterious. The XML editors in Visual Studio and Kaxaml give me a sad, and Resharper's WPF functionality is, let us say, a work in progress. I much, much prefer the tools for WinForms that make it possible for me to smoothly and rapidly build the slow, quirky, and unmaintainable crows' nest of code that I'm coming to loathe.

Answer 9

WPF is a great framework for creating apps. And when you combine it with a good GUI architecture such as MVC, MVP or MVVM it is brilliant at making interesting looking line-of-business apps with more pizazz than your standard WinForms application.

XAML on the other hand is the ugly cousin that comes along with WPF. The main issue with XAML is the tooling. The tools are worse than non-existent, because they make people think that there is a WPF designer like WinForms, when infact most devs I know use the equivalent of notepad to develop their XAML.

The other tooling issue with XAML is the compiler. XAML is only slightly better than magic strings. The compiler can't pick up most mistakes you make in XAML, and some mistakes won't even crash your app. Instead WPF will print an error message to your output and carry on.

Answer 10

On the question of tooling, I will concede that building WPF and Silverlight Apps in Visual Studio 2008's designer has required quite a bit of expertise to get right. However I hope you'll give a look to the improved designer in Visual Studio 2010 - it has many more features that we hope will make sense to the Windows Forms developer for building business forms, whether in Silverlight or WPF.

Check out these videos: Data Binding and Forms Tools Styling Tools Futures New Features in Beta 2

And get the Release Candidate here:

The team has a new Blog here

I hope you find this useful info - if you've already tried Visual Studio 2010 I'd love to hear your feedback. Send me mail at mwthomas at microsoft dot com.

Thanks Mark Wilson-Thomas Program Manager, WPF & Silverlight Designer, Visual Studio

Answer 11

IMHO, Microsoft gave some clues about it's future path by developing VS 2010 in WPF.

WPF is no more, no less than WinForms. It has a totally different and extensible way of UX design.