WPF vs Windows Forms

Abstract:

This point of view will try to look at two main technologies provided by Microsoft for building rich Client Applications namely Windows Forms(Win Forms) and Windows Presentation Foundation (WPF). We will try to identify which of the two should be used/recommended for developing  Client Applications.

Introduction:

Windows Forms has been around for a long time and in that time there have been numerous applications built using this technology. This was preferred and in most cases the only possible way to create rich client applications in Microsoft technologies. Windows forms were used by small and big corporations for all types of applications like data entry to dashboards, it has its advantages with a rich set of controls, drag, and drop of controls, and is extremely useful for creating applications quickly without much formal training. Anyone with average knowledge of programming be it VB 6.0 (predecessor to Windows Forms), C# can quickly get started with Windows Forms and be productive.

Then came Windows Presentation Foundation (WPF) formally known as Avalon which was release with .Net framework 3.0.

WPF is to Win Forms as AS.net MVC is to ASP.net

The above quote does not intend to comment on the popularity of Win Forms or ASP.net. ASP.net is still quite prevalent and new LOB applications are being developed using ASP.net. It tries to show the advancement and direction in Client and Web application stack with WPF and MVC.

WPF brought the fundamentals which were previously thought as specific to web applications like Model-View-ViewModel pattern (MVVM), loosely coupling between User Interface(UI) design and Business logic, dynamic bindings, support for Unit testing into the world of Client Applications. WPF works on the concept of dividing the responsibilities between a designer and a hardcore programmer (we all know how good are programmers with colors and gradients). WPF was never developed as an extension or next level of Win Forms but is a whole new platform for creating client applications. WPF also released developer from the responsibility of worrying about DPI for their applications which it can handle itself very gracefully. WPF uses Extensible Application Markup Language (XAML) for UI design which has become one of the mainstream features of Microsoft technology stack for client application development, Windows Phone Development, and even Windows 8 App development, is the most compelling reasons for developers to move into WPF.

This point of view (POV) does not declare than WPF is the hands-down winner to create rich Client application though there are compelling reasons to go for WPF for almost all the client application needs, but, I think there is still some space for Win Forms especially for prototyping and applications which do not have a client base.

We will consider some of the major points for Client Application development and try to look from the eyes on both Win Forms and WPF.

Rapid Application Development (RAD): Paraphrased from Wiki, RAD is a software methodology that allows developers to write software in form of prototyping, creating UI quickly and getting feedback from the customer at the runtime. This is easily possible with Win Forms (with no previous knowledge of creating client applications) as compared to WPF. WPF does provide a much more extensive set of features to customize UI with more eye-catching stuff but developer should have some basic understanding of either tool like Expression Blend or XAML. Hence, for creating small prototypes that can be used to showcase functionalities to the customer quickly Win Forms can be a better option.

UI Construction: WPF takes a whole new level for creating UI design for applications, with the concepts of Skins, Themes, Templates, and the flexibility provided by XAML to imbed literally any control inside another control. Win Forms by default do not provide this level of flexibility through applications developed with Win Forms also have glossy and eye-catching looks, but, it's much easier to create these features in XAML. Also, because of loosely coupling between XAML and the code behind developers can very easily work in a plug and play manner wherein, designers can design templates and resource dictionaries and developers and create business logic. Providing and changing themes at runtime is also another short in the arm of WPF.

Technical Debt:  The term originally coined by  “Ward Cunningham” which means incurring debt on software developed by doing things in a quick and dirty way and paying it off later by refactoring the code or fixing bugs because of incorrect design decisions (you can read a very good article by Martin Fowler here and here). An important thing is that developers should be aware of the design decisions they make and their tradeoffs in order to deliver the product quickly and efficiently. Technical Debt can be reduced right the start of application development by following some basic guidelines which help in keep code maintainable and scalable for future requirement, WPF here has a big advantage with some well-known features and frameworks which can be directly plugged in and will make sure software being developed has basic structure working properly like implementing MVVM design pattern, having code loosely coupled, Unit Testing for components separately. Though this can be implemented in Win Forms as well there are no built-in frameworks that can be utilized and hence it becomes the responsibility of the developers to maintain the integrity of the code. Win Forms code has more probability to become spaghetti rather than WPF code implemented using MVVM or similar design pattern.

Bindings: This feature requires a special mention when deciding between Win Forms and WPF. INotifyPropertyChange (INPC) is in the heart implementing data binding between properties and views. In WPF INPC is a first-class member and is used for all the UI interactions with the respective model. Though this feature is now available in Win Forms as well, it's not as well integrated as in the case of WPF and developers need to have a deep understanding of binding to use it effectively.

Windows Store App and Beyond: Microsoft has chosen a direction and its not Win Forms. Microsoft allows developers to create phone and store apps using web technologies like HTML and JavaScript as well as XAML. Hence, developers do need to move to XAML based technologies in this ever-changing landscape and that’s a good enough reason for developers personally to lean and start using WPF.

Non-Technical Considerations: This does not have the same significance for developers/architects but can be an important consideration for Project managers who should look at the skill set of the developers, cost, and time tradeoff for delivering projects. WPF no doubt has a bigger learning curve compared to Win Forms and that should be something which should be considered while planning for the application. Having said that this will also depend on the type of application and targeted audience because even though it may take some initial time to start getting output from WPF if today there is to be software developed which has significant user base WPF will be the way to go. But, if we need to create some prototype for a feasibility study or an application where UI design is not a priority and the code base will remain constant without any further enhancements we may get better productivity with Win Forms.

Conclusion:

Win Forms do still have some market though it's shrinking. But, if you are building applications that don’t need extensive UI design, ever-changing code base then Win Forms can still be a viable option. Win Forms has a low learning curve and can be very useful for prototyping and demo applications to showcase functionalities. But, developers as well as managers cant ignore WPF now, any production application which is going to have a significant user base and is a LOB application then WPF is the way to go.

If teams are still working on existing LOB application on Win Forms then senior developers and managers should make sure that teams are learning and getting comfortable with WPF so when the time comes there is a seamless movement. Win Forms can use WPF controls and if the application is already in production teams can plan a staggered migration to WPF using interop support.