Should I use WPF or WinForms for a major re-write?

[Frinavale]

Those of you who know me know that I am not a windows-client developer. My technology of choice is ASP.NET and other web technologies. So, I am a fish-out-of-water when it comes to providing insight into which Windows desktop-client technology is best suited for a business's software needs. I have dabbled in Silverlight and I have created a few fairly simple WinForms applications, but for the most part I am a newbie to the Windows desktop-client development world.

I have been trying to decide whether to use WPF or WinForms for a major re-write/redesign undertaking of some existing software. And the deadline for completion of this new software is much closer than I would like it to be.

To help me decide, I started out by creating a WPF application to experience using this technology first hand and then I attempted to create the same thing in a WinForms application.

Originally, I was under the impression that WPF was mainly used for eye-candy user interface (UI) design (with it's support for animations and skinning features). I am not a fan of really flashy UI since it these designs usually take up my time doing some silly animation. So, I was a bit skeptical about WPF. But what I found was that this technology is much more than just flashy stuff.

WPF's use of templates and data-binding is incredibly flexible. Business logic validation can be done by the UI without any code in the UI or the code-behind for the page/control/window. The hard things for me had to do with skinning but I think that's mainly because I do not have the appropriate tools to do what I was trying to accomplish (I don't have access to Expressions Blend and was learning how to do things by hand).

When I created the WinForms application I found that I was very constricted by the controls that were available to me. I truly missed the template and binding features in WPF... but at the same time working in WinForms was much more familiar to me even though I am coming from a web-development background.

WinForms seems to be a good choice considering the time constraint, and the fact that most of the team is coming from a VB6 background.

However, WPF is a powerful, flexible, framework that promotes good business logic class design (since the application is driven by binding to these classes). Also, since our application involves embedding live video streaming, graphics, and even has a component that requires objects be dragged around a "desktop" and placed in desired spots... I can see a lot of advantages of using WPF.

Since I do not have a lot of experience using either of these technologies, I am putting the question to you:

Which would you recommend moving to, WPF or WinForms?


-Frinny

[Niheel]

Just from a project management perspective.

Two things you metioned:

• The time constraint
• Lack of experience with these technologies
• Working with a team

I would go with the one that you're the most familiar with. Even if it's by the slightest. You noted that the team would be more familiar with VB6, making WinForms ideal.

If you guys have more time and can all get on board with WPF, then that's a different case.

Just a thought, keep us posted on which way you go.

[Steve N]

What's the original software in? I am assuming vb6? I just completed a project this month doing a migration, not a rewrite , for a 200k line complex vb6 app to winforms using a company called ArtinSoft. Project went very well. 4 months to do it too. We are now stabalizing and refactoring and will be moving towards wpf as we go and learn it (MVVM).

Skip the rewrite, migrate.

[Hugo Dahl]

Slight disclaimer: I am presently a very happy WPF developer, though I have done HTML, ASP, ASP.net, Quickbasic, C, C++, VB (versions 3.0 - 6.0), VB.Net, C# and Winforms in the past.

There are several important factors which will weigh into your decision. You have mentioned several internal, be they to yourself, your team or the business. However there are also external factors which should be considered, separately and jointly.

Since this is a rewrite from another application, I presume the application has been around for some time, with features and functionality added over time as needed. So how long will you be supporting this application and it's current technology set? Also, bear in mind that Winforms technology will stay where it is, with no future enhancements or functionality added by Microsoft. WPF is their UI presentation technology platform from this point forward. So if you are going to be supporting this version of the application for 10 years, you will be on 10 year old technology at the end of the lifecycle.

Given that the current skill set on your team is fairly even between Winforms and WPF, and coming from a VB6 familiarity, I would actually recommend the WPF route, for a number of reasons.

• It is the backed UI presentation technology from Microsoft for now and the forseable future
• As you mentioned, you can create Control and Data templates, which can then be reused throughout the application. Though it may take longer to create the first time around, that is the only time you would need to create it, and then reuse everywhere
• Using WPF and the recommended M-V-VM design pattern (with a specialized library or not), proper design and separation of concerns such as in a classical n-tier design are much easier to implement and follow. The Model is the data, the view model is how the data is meant to be interacted with in the UI, and the view is the UI
• It also makes it much more difficult, if not nearly impossible, to bring the bad development habits that may have developed over the years in VB6 to the new platform
• Data binding and data interactions from the UI tier are, for the most part, simple, requiring little to no code behind to work
• You can have two groups in your team, one focusing 100% on the visuals (XAML, Converters, etc) and the other on the logic, mitigating the need for all developers to become well rounded enough in all aspects of the new platform

Several of my points presume going with the M-V-VM pattern, particularly the last one, for which I will go into more detail here.

You can split a team into 2 groups, one with a focus on the visuals (View layer, possibly also the ViewModel depending on what other portions of the system already exist, if any) and the other on the business logic and data repository interactions. As long as both sides have a contract (interface) that is agreed upon by both sides, they can work on their own portions and "meet in the middle". Meaning that the UI group can create fake/mock/stub objects which implement the interface, to use as their data source or data context, because the other group will be exposing the data to them in exactly that manner. The same with the "data" group, who can test that the data coming out of their end through the interface is exactly as it should.

I know that I've mentioned a lot here, and it's a decent chunk of information to digest, but I hope that it helps you in making your decision, no matter which way you choose.

Hugo

[Alex Papadimoulis]

Lots of good discussion and points have been raised thus far, but there's another consideration... WPF is less mature technology.

While it's certainly true that WinForms are "only" 9 years old, it's a natural evolution of the paradigm that defines Windows development from Windows 1.0* to VB6 through even today (non-.NET development). WPF is a fundamental shift from this paradigm.

Mature technologies will offer less risk while newer technologies provide the ability to do more with less. Mature technologies also offer the benefit of collective knowledge and experience, and there are a lot more questions/answers on the web regarding them. There are less resources available for newer technologies.

The point in this is to make sure to consider your team. A group of “rockstar” developers can often mitigate the risks, but most teams (mathematically speaking) are average. Obviously, only a select few can be “the best”.

Here’s a quick anecdote to illustrate/remind the problems with newer technologies. When my team explored WPF, we ran into a deal-breaker after deployment: the text was “blurry” on many clients. Apparently, this is a “known feature”. For us, the solution was simple: disable ClearType in the registry or upgrade to WPF 4. We would have been in serious trouble if neither was a possibility.

* from what I’ve heard and read in Old New Thing, at least; I got my start in Windows 3.x, so I don’t know what a 1.x is like first hand