After three months of trying to hammer out a line-of-business (LOB) application on WPF, I reached a point of considering turning back to Windows Forms for my project, and in researching other people's opinions, came across this thread...
Yes, WPF is a brilliant technology and it has benefits that span far beyond mere eye-candy... the templating and binding capabilities are great examples. The whole object model offers more flexibility and broader possibilities. That doesn't, however, make it the defacto platform for future LOB applications.
The "problems" which WPF solves in terms of separating GUI from business logic aren't problems which can't be readily solved in Windows Forms by simply starting with the right architecture and mind-set. Even the object-path binding capabilities of WPF can be reproduced in Windows Forms with some very simple helper classes. The data template capabilities of WPF are very nice, but again they're nothing that you can't simulate in Windows Forms on those rare occasions when you absolutely don't know exactly what objects you're going to represent on any given part of the screen.
Where Windows Forms races ahead is in terms of maturity. You can't swing a dead cat on Google without hitting some blog where someone has solved a Windows Forms problem for you. WPF, on the other hand, has comparatively less learning resources available, fewer custom controls available, and hasn't had as many of its teething problems solved.
At the peak of making a WPF vs Windows Forms decision has got to be the maturity of the development environment. Windows Forms editors are slick, responsive and intuitive. Feedback about errors gets to you instantly, the solutions are usually obvious, and the compile->debug->edit cycle in Windows Forms is very quick.
WPF applications, on the other hand, have comparatively pathetic design time support, with the design view all-too ready to chicken out at the first encounter of an error, often requiring a project build after the fix before the designer is willing to kick in again. Drag'n'drop of components from the toolbox might as well not be supported, given the vast range of circumstances under which it either doesn't work at all, or yields completely unintuitive results. Despite the promise of the WpfToolkit, there still isn't a usable DataGrid for WPF that yields any kind of resonable performance or design time friendliness.
Debugging WPF applications is a bit like the old ASP.NET debugging paradigm... hit F5 -> wait -> launch -> error -> stop -> fix -> hit F5 -> wait -> launch -> error -> groan -> stop -> fix -> hit F5.... All XAML which your program is running is locked, and tracking down XAML specific problems is often tedious.
The bottom line, simply put, is that the development tools for Windows Forms are going to have you banging out front-ends in a fraction of the time of a WPF application... especially if you're creating master-detail grids or spreadsheet like interfaces, which most LOB have. With Windows Forms, you start with 90% of the work already done for you.
I'm a huge fan of the WPF architecture. I just wish the design-time tool-set didn't feel like a pre-alpha debug-build.
Edit: This answer was posted about .NET 3.5 + Visual Studio 2008, but .NET 4.0 with Visual Studio 2010 ships with a WPF data grid. While many improvements have been made to the new WPF development experience, my answer here remains unchanged, and I'd like to add the following suggestion:
If you're in a rush to do RAD development, go with Windows Forms. If you're looking to produce a well architected, maintainable, scalable, resource firendly, multi-user Line-Of-Business application, consider ASP.NET MVC + HTML 5 + jQuery... My projects with these technologies have resulted in better outcomes, sooner, for my customers. MVC offers all of the same templating that WPF does, and jQuery enables animations and complex interactions. More importantly, an ASP.NET MVC + jQuery solution doesn't require your end users to have modern desktops with decent graphics hardware.
I'm seven months into using WPF on what has now become a core system for my customer, and I'd like to share some more thoughts with you about the experience of learning and using WPF as a line of business presentation platform.
In general, the comments I made above still hold... The design time support for WPF isn't here yet. If you're in a big rush to get a rich-client application out of the door, go with Windows Forms. Period. Microsoft aren't in any hurry to discontinue the GDI / Windows Forms platform, so you can count on good support for a fair time into the future.
WPF is not easy to master, but that shouldn't be where you leave your descision about whether or not to invest your time and energy into learning WPF. Despite its present lack of maturity, WPF is built around some useful, modern concepts.
In WPF, for example, your investment in well-written business objects with sound validating logic is a solid investment. Unlike Windows Forms, WPF's data binding is briming with features that allow interface controls to react to invalid user input without writing GUI code to detect those errors. This is valuable.
The styling and templating capabilities in WPF have proven to be valuable too. Despite the common misconception that the only use for styling and templating is to create on-screen eye-candy, the truth is that these features significantly simplify the coding of a user interface which gives rich feedback - like buttons that disable/enable themselves base on the state of the underlying business logic layer, or tooltips which intelligently find their text based on the state of the object under the cursor, etc.
These all add up to incredibly valuable features for "nothing fancy" business applications, simply because they make it easy to keep the interface congruent with the underlying data.
In a nutshell:
It's a seemingly subtle difference, but it makes a huge difference in your ability to re-use code... which begs the question: "Is the Windows Forms vs WPF question actually an investment decision?"
(This seems to have become my favourite thread.)
Are there any compelling reasons to use WPF
Absolutely! WPF is absolutely incredible! It will be a major benefit for practically any project because it has so many features and abilities that Windows Forms lacks.
For business applications the biggest wins will be:
For utilities and games, other advantages come to the forefront:
The bottom line is that any significant-size GUI you could build in Windows Forms can be built in WPF in a third of the effort (or less) and look way, way better.
Does WPF require more resources (RAM in particular)
You do pay a price compared to Windows Forms, but it is a small one.
One more note about CPU use: Animations and transforms (motion, translation, etc.) is actually more efficient on WPF than in Windows Forms because of its retained mode storage. It is the initial getting of the objects up there that is slower.
Maintenance overhead
WPF is a huge win over Windows Forms when it comes to maintenance. Since everything is done in 1/5 as much code as before, there is 1/5 as much to maintain. Plus all the boilerplate stuff is gone so you can focus on the code that actually does the work.
Benefits of XAML
XAML is the core of WPF. Although WPF can be used without XAML, XAML makes it incredibly easy to use. XAML has HTML's ability to easily specify a user interface, but its built-in tags are much more powerful, and you can easily define your own. (In fact, it is normal to do so).
Some specific advantages of XAML:
Other insights
I dreamed of something like WPF for many years. Many people have implemented portions of this functionality, but to get it all in one place and at such a price ($0) is amazing.
WPF is a huge paradigm shift from Windows Forms and will take some getting used to, but the time spend learning it will pay itself back many-fold.
WPF still has a few warts even five years later, but its power will totally blow you away once you experience it. If someone tries to drag you back to Windows Forms, you'll only go kicking and screaming.
Tips: - Do get a copy of Expression Blend for development - Do edit XAML by hand occasionally - Don't give up when it seems strange at first
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
WPF requires either Windows Vista or Windows XP SP2, which is not an onerous requirement, but it is a relevant one. If you want to run on Windows 2000 (which some people still do), then WPF won't work for you.
WPF is also a newer technology and not as proven as Windows Forms so you might choose Windows Forms as a less risky option, particularly for larger applications.
That being said, yes WPF is the future. Visual Studio 2010 is being rewritten in WPF, which will probably be the largest WPF application to date and it will also be a real test for the technology.
Obviously, legacy Windows Forms applications would be another situation where it is the correct choice.
As others have said, there are advantages and disadvantages either way you go here. The advantages of WPF, as others have said, include:
However, there are drawbacks to WPF, where Windows Forms comes out on top:
Finally, bear in mind that you can create great, attractive and engaging UIs in either tool, if you do the work (or use the right third-party tools). At the end of the day, neither is necessarily better in all circumstances. Use what feels right for the project.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With