tags:

views:

834

answers:

7

Hi,

I'm wondering if there are people out there with experience of WPF application development - and maybe more interesting - running WPF in production.

Is it mature enough to use in larger projects? What are the obvious pitfalls? Any best practices? (Databinding in WPF seems pretty nifty but does it work in 'real' projects?)

Thanks in advance!

+17  A: 

WPF came out with .NET 3.0. We're on 3.5 sp1, so if its not production ready MS has got a lot of essplainin' to do. Frankly, it was production ready when 3.0 came out.

I'm currently working on a project that uses WPF for templating and databinding (not for UI display, but I use UI classes to define templates). I've also used WPF for personal stuff. And, quite frankly, I'd have to be beaten severely to even consider using windows forms for UI. WPF is beautiful in its simplicity and flexibility. Its databinding facilities are spectacular compared to the hacked-together windows forms binding models. And XAML is a revolutionary step in software design, imho.

Databinding in WPF is not just nifty, it also allows you to implement some pretty good architectural designs. This is a good post that covers some of the more popular ones. Think of it like MVC/MVP on steroids.

Long story short, run. Don't walk.

Will
I'm with you. It's like Tivo. Once you've tried WPF there's no going back to WinForms.
Ray
Interesting. Are then any third party controls for it yet? (Or is it so easy I can just write my own smart controls...) Maybe I should post a question about this...
Christopher Edwards
Yeah there's quite a few 3rd party controls. DevExpress has some good ones (I've only played with them, haven't used them seriously yet).
Ray
Lots of them. But WPF controls are so flexible that its almost trivial to skin them.
Will
+2  A: 

Actually I think that the answer is yes and no...

The no part in my experience has been the tooling that is available for WPF. Right now today it is a very steep learning curve and one of the things that is needed desperately is great tooling to make the technology approachable, for example the level of integration of expression blend / studio and Visual Studio is very poor. IMO simple tasks should be simple and Complex tasks should be possible, with WPF complex tasks are indeed possible, but simple tasks are complex also.

Having said all that, if you do get through the learning curve, and can cope with the sub-par tooling the resulting apps are certainly production ready.

Tim Jarvis
+4  A: 

I'm not sure if it's mature for large things, but it sure is ready for midsize database-driven apps if that's your cup of tea. I made a patient management system using WPF+SQL Server 2008, and didn't have that much trouble.

Pitfalls - I've got one - fonts. Seriously, how do you explain your non-tech-savvy client that there's nothing that can be done to improve WPF font rendering on XP? This area is very painful, and it doesn't look as though Microsoft is addressing it. (Please correct me if I'm wrong.)

Best practices? Umm, yes, you mention databinding, that works quite well, though of course it inhibits clear tier separation somewhat. I actually think most of the ideology inherited from the WinForms era still applies, provided you've managed to start thinking about UI differently. My best practice for WPF has been to use code generation to map out a database into a series of controls kept in a WrapPanel. In fact, these wrap panels are great because they scale to any screen size, and layouting actually feels smooth and natural.

Dmitri Nesteruk
From what I've read, I think MS *is* addressing the font issue for .NET 4.0. The fact VS2010 using WPF for the text editor window is going to force the issue somewhat...
Will Dean
Unfortunately, that means that you'll have to wait not just for .NET 4.0, but for your customers to roll it out. That could be years.
PeterAllenWebb
+1 for mentioning the bad font quality. Seems also to be a problem in Silverlight.
kay.herzam
It gets even more interesting than that. Seen VS2010 yet? It uses WPF for the code editor. Guess how well the fonts get rendered there :|
Dmitri Nesteruk
+5  A: 

I would say yes, it's production ready, and has been for a while, but there are a few caveats with that:

  1. The tooling is far from perfect. Visual Studio design surface is terrible, although the autocomplete in text mode is fine. Blend is an excellent product, but still unstable (which it really shouldn't be) and it's "loose coupling" to XAML can be very annoying.
  2. Performance. If you start to use fancy graphics, effects and animations (even subtle ones), then you need to keep an eye on your target platform. It's very easy to put something together that works great on your development platform, but runs like a 3 legged donkey on a "client" PC.
  3. Learning curve. Although I think the steep learning curve with WPF is a bit over egged, it does take a bit of time to start thinking in a "WPF way", and there are generally a lot of ways to do most things. For example, most devs will create their first WPF app using bind/re-bind rather than using ObservableCollection and the like.
Steven Robbins
+1, very disappointed in Blend when I used it; not worth paying for.
jcollum
+2  A: 

Speaking for a small company who's main purpose is getting the Business of the company in the app. I must say that wpf is not ready.

Not that easy to maintain, not (very) straightforward, and the developers lose too much time in getting the UI right instead of writing Business code.

We are going back to smart client ;)

Kind regards, Wim

hypo
+2  A: 

The important thing is that you must adapt yourself to WPF, and not trying WPF to fit you. You have to forget all you know about UI programming (winform or spring). If you think WPF is like winform, your life will be a pain... This technology is production ready, it's your code which may be not... Take the time to learn about good programming practices in WPF, and your code with WPF will be "production ready".

Nicolas Dorier
+1  A: 

My Experience with WPF on a small team.

I would agree with Hypo and say yes and no.

I am a 1 of 3 corporate developers, we are in the sports industry and one of projects is tournament software. I recently rewrote our score/bracket display app in WPF. The displays are 100% prettier but it was not easy. The learning curve was huge coming from WinForms the binding is powerful but equal parts complex. I have a ton of problems with WPF in VS 2008 it Crashes my IDE at least once a day, I often have to delete my user files or opening properties on the project file closes my IDE. Running animation on XP SP3 seems to be smooth on only 50% of our XP sp3 machines the other 50% there is a ton of ugly artifacts and the forms do not seem to redraw correctly. My XAML editor will sometimes freak out and I have to close the tab and reopen it. All problem I am quoting are happening consistently across 4 different machines.

My final answer yes to the Framework. No to the tooling I wasted way too much time fighting my IDE. No for small teams that just need to get some quick line of business apps out. Once there are more controls, Themes, project template, and it works under VS. I may change my mind.

Despite my intense PAIN learning WPF/XAML its still exciting to work with I am often blown away at some of the cool stuff you can do.

Aaron