WPF vs Windows Forms vs MFC

WPF vs Windows Forms

WPF is not just for applications which simply require “eye candy.” That is the most common and frustrating misperception about WPF which I’ve encountered. Sure, WPF has a lot of support for flashy visuals and animations. But that’s not all it’s good for. If you’ve worked with WPF for any substantial period of time you are probably well aware of this fact, so I won’t keep harping on the issue.

The true power of WPF resides in the data binding mechanism and the way it shares resources across the application. On extra benefit that comes from the learning curve is that who learn how to decouple logic from UI. It’s not because of a pattern, but because of the data binding mechanism. Truly an application will last longer, when the UI can be changed without producing problems to the logic. Use the templates right and you can change a piece of UI code that reflects to the entire application. And don’t get me started about the usage of Control Templates.

WPF is an especially great platform to use if your applications involve various media types.

For example,

1. If you need to incorporate video, or documents, or 3D content, or animated transitions between a sequence of images, or a combination of any of the above.

2. WPF is also great if you need to create a skinned user interface

3. If you need to bind to XML data

4. Dynamically load portions of a user interface from a Web service

5. Want to create a desktop application with a Web-like navigation style.

WinForms definitely still has a role to play, despite the fact that WPF has hit the scene. If you are building applications with no need for the extensive modern functionality in WPF, then there is no compelling reason to leave behind a time-tested developer-approved platform. WinForms certainly has more 3rd party controls available, online resources, developer communities, etc. than WPF currently does. It’s much easier to find WinForms developers than WPF developers. Also, WinForms currently has a much better design-time experience in Visual Studio than WPF. That fact alone is a very compelling reason to stick with WinForms for a while.

Lastly, don’t forget that it is possible to use WPF controls in a WinForms app, and WinForms controls in a WPF app. If you have a substantial investment in a WinForms code-base, but want to use some aspect(s) of WPF, you can leverage the interop support to make that possible. Just be sure to read up on the limitations involved with WinForms-WPF interop before getting too far down that path.

WPF Positives & Nagatives

+ Powerfull styling and skinning structure
+ Easy to create an own Look and Feel
+ Does support Windows Forms
+ The future technology for developing Vista Applications
+ The ability to reuse existing code
+ Highly advanced databinding possible
+ Declarative vs procedural code
+ Vector Graphics simplifes painting Operations
+ 3D
+ Animations
+ WPF Everywhere Idea (Silverlight and Microframework)
- Requires .NET Framework 3.0
- Compared to Windows Forms, still in development fase
- Requires Dx9 compatible vidcard for advanced graphics

Windows Forms Positives & Nagatives
+ Extensive documentation to be found on the internet
+ Plenty of examples
+ Does support WPF
- How long will this be supported? (I've read somewhere that Microsoft is only developing WPF now, only maintanance for Winforms)
- Design your own look and feel in a application is a lot of work.


Windows Forms vs MFC

If you are accustomed to MFC, you might be used to creating certain types of applications that are not yet explicitly supported in Windows Forms. Windows Forms applications are equivalent to MFC dialog applications. However, they do not provide the infrastructure to directly support other MFC application types like OLE document server/container, ActiveX documents, the Document/View support for single-document interface (SDI), multiple-document interface (MDI), and multiple top-level interface (MTI). You can write your own logic to create these applications.