views:

3614

answers:

10

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?

+3  A: 

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.

Cody Brocious
+13  A: 

I think it is worth learning WPF. Once you are up to speed, design work on your forms is much easier IMHO. I wouldn't worry as much about the 'sexy' stuff. Most of this is just a fad. You can make 'normal' Winforms-style applications very quickly and easy in WPF.

The whole concept lends itself to easier design IMO.

Geoffrey Chetwood
I agree with Rich. The sexiness of WPF has been way over emphasized. I think that is a great technology that offers some very compelling arguments to use it ... for standard, run-of-the-mill business applications.
cplotts
+18  A: 

There is a very steep learning curve to WPF and I recommend you get the obvious books first (Adam Nathan, Sells/Griffiths, Chris Anderson) and Blogs (Josh Smith, etc.). Just be prepared for it and make sure your project allows you the time to learn WPF.

In addition to learning the technology spend some time learning the patterns used to construct WPF applications. Model-View-ViewModel (MVVM) seems to be the one that has gained a great deal of acceptance.

Personally, I think WPF is worth it but be forewarned. Also note that you effectively restrict your users to Windows XP SP2+ / Vista. We've made that decision but you may have some different requirements.

dpp
+4  A: 

if you have an MSDN License, check out Expressions. It's designed explicitly for WPF, exports directly to Visual Studio and it may help ease your transition.

Rob Allen
+11  A: 

We are currently rewriting our application in WPF from Winforms. 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 VS for years. Yes, it's mainly for designers, but some things you just can't do in VS.

Scott
Yes, "writing less code, faster, and more robust than ever" is a great way to describe the WPF experience. It is not really about eye candy at all. By the way, since this was written Expression Blend has been released, is already to version 3, and is very slick to use - better than any VS.NET designer ever made.
Ray Burns
+3  A: 

As a side bonus, Silverlight is based on WPF and starting with either lets you gain the know how for working with the other. If things continue to go web based, having prior knowledge (and a library of existing code) to transfer easily to the browser (or Windows Live Mesh) might help give your software an extra lease of life.

Nidonocu
+3  A: 

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

Vin
I enjoyed especially the first 25 minutes or so of this video where Billy Hollis shows off some of the capability differences between WPF and WinForms.
Ray Burns
+41  A: 

WPF enables you to do some amazing things, and I LOVE it... but I always feel obligated to qualify my recommendations, whenever developers ask me whether I think they should be moving to the new technology.

Are your developers willing (preferrably, EAGER) to spend the time it takes to learn to use WPF effectively? I never would have thought to say this about MFC, or Windows Forms, or even unmanaged DirectX, but you probably do NOT want a team trying to "pick up" WPF over the course of a normal dev. cycle for a shipping product!

Do at least one or two of your developers have some design sensibilities, and do individuals with final design authority have a decent understanding of development issues, so you can leverage WPF capabilities to create something which is actually BETTER, instead of just more "colorful", featuring gratuitous animation?

Does some percentage of your target customer base run on integrated graphics chip sets that might not support the features you were planning -- or are they still running Windows 2000, which would eliminate them as customers altogether? Some people would also ask whether your customers actually CARE about enhanced visuals but, having lived through internal company "Our business customers don't care about colors and pictures" debates in the early '90s, I know that well-designed solutions from your competitors will MAKE them care, and the real question is whether the conditions are right, to enable you to offer something that will make them care NOW.

Does the project involve grounds-up development, at least for the presentation layer, to avoid the additional complexity of trying to hook into incompatible legacy scaffolding (Interop with Win Forms is NOT seamless)?

Can your manager accept (or be distracted from noticing) a significant DROP in developer productivity for four to six months?

This last issue is due to what I like to think of as the "FizzBin" nature of WPF, with ten different ways to implement any task, and no apparent reason to prefer one approach to another, and little guidance available to help you make a choice. Not only will the shortcomings of whatever choice you make become clear only much later in the project, but you are virtually guaranteed to have every developer on your project adopting a different approach, resulting in a major maintenance headache. Most frustrating of all are the inconsistencies that constantly trip you up, as you try to learn the framework.

You can find more in-depth WPF-related information in an entry on my blog:

http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx

AndyL
I love the fact that you pointed out the issues on integrated graphics chips. This has bitten us more than once. Pain, oh, the pain.
cplotts
I also like that you pointed out what you call the "FizzBin" nature of WPF. There really are so many ways to do things that it is hard to know (especially when you are just starting out) what way is the best way. If I could give you two thumbs up, I would. Nice answer.
cplotts
@AndyL: +1, we're enjoying the growing pains of learning WPF and unlearning WinForms!
sixlettervariables
some very interesting and well grounded points
Christian Hagelid
+1  A: 

Scott above was complaining about Blend and how it doesn't make sense to him as a developer. My first reaction to Blend was this. However, now I see it as an invaluable tool, but it really depends on what type of developer you are.

I am user interface developer that has had to perform the Integrator role and I eventually found Blend invaluable to create styles, control templates in a WYSIWYG manner. I almost always have Blend and Visual Studio up an running on the same project at the same time.

I also think that playing around in Blend and taking a look at the xaml that gets spit out is an excellent way to learn the WPF API ... much like using the designer in Windows Forms and checking the C# code it spits out is helpful in learning how to use whatever you are designing there.

Blend is helpful ... just give it a try ... especially if you are working on the visuals for the application.

cplotts
+3  A: 

In DotNetRocks episode 315, Brian Noyes discusses this extensively.

Jim Anderson