When should one use WPF instead of WinForms, and vice versa?
First off, 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.
WPF is an especially great platform to use if your applications involve various media types. For example, 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. WPF is also great if you need to create a skinned user interface, or if you need to bind to XML data, or dynamically load portions of a user interface from a Web service, or want to create a desktop application with a Web-like navigation style.
Another great reason to use WPF is if you have a team of developers who are bored with WinForms and are itching to get into something new and cool. Of course this is not as powerful and compelling a reason from a business perspective, but nothing promotes employee retention better than keeping the employees interested in their jobs.
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.
Ref: http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/
First off, 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.
WPF is an especially great platform to use if your applications involve various media types. For example, 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. WPF is also great if you need to create a skinned user interface, or if you need to bind to XML data, or dynamically load portions of a user interface from a Web service, or want to create a desktop application with a Web-like navigation style.
Another great reason to use WPF is if you have a team of developers who are bored with WinForms and are itching to get into something new and cool. Of course this is not as powerful and compelling a reason from a business perspective, but nothing promotes employee retention better than keeping the employees interested in their jobs.
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.
Ref: http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/
