Advantage of WPF app vs Winform for business apps? [closed]
I know asp.net and winform development. I am not the type of developer who jumps into a new technology just because it's new. It needs to give me extra benefits like higher productivity.
For my team, WPF has proven to be much faster than WinForms to develop applications with. We recently released a mid-sized app in 32 man days. We had the advantage of an experienced WPF developer on the team, and inexperienced guys who were eager to learn the technology. There was great morale, and productivity was impressive.
WinForm is a mature proven technology and I like the fact I can do everything in Visual Studio vs multiple IDE's for WPF (VS & Blend family).
Do you consider yourself a hand-coder, or a drag-and-drop coder? If you consider yourself a drag-and-dropper, than the current crop of WPF tooling may not be suitable for you. Maybe wait for Visual Studio 2010? I work almost exclusively in XAML. Most WPF'ers will probably agree that this is the most effective way of creating WPF applications at the moment. But then, I also craft my HTML by hand, so it feels natural to me...
What are the advantages of WPF over Winforms for pure business apps? I am not interested in the extra eye candy, animation, gradients, image display effects and so on which WPF provides.
I used to think this way, but I have recently developed a business application which has gradients, basic animation and effects. These fancy features were added to enhance the user experience. Why should business apps be Battleship Grey? Why should they be unusable? Granted, it isn't color, gradients, animation that makes a business app usable, but using these effects can help the user experience, and this is what is important to me. I could have done everything I did in the WPF app in WinForms - it just would have taken much longer.
Better richer data binding?
The databinding support truely is amazing. It is my single most-loved feature in the platform. Check out this wonderful Databinding Cheatsheet.
Try to convince someone like me to switch.
I have decided that I am not going to try and convince anyone else to switch to WPF. The developers I have tried to "convince" (all experienced Winforms developers) usually have struggled with the platform. They are not invested in the technology. They don't "get it". I encourage people to check out the technology to see if it is right for them as a developer. The learning curve is huge. If you learn by books, check out this SO post for some mini-reviews on WPF books. If you learn by videos, check out the windowsclient.net WPF videos. If you learn by example, check out this or this post. Forget everything you know about WinForms. WPF really seems closer to ASP than WinForms. Create some sample applications. See if it works for you and your team.
As you are multi-skilled (asp.net/winform skills), you may see the advantage of skilling-up in WPF as it is very closely related to Silverlight. Silverlight fills that gap between your rich client applications and web applications.
I personally feel WPF is the best client side technology available for the .NET framework, and will generally avoid developing in WinForms for future work. YMMV
Good luck with your decision.
I have quite a bit of winforms experience and have only played with WPF a little bit, but I'm sold.
Why?
MUCH more flexibility. If you want to do anything non-standard in winforms, pain and suffering ensues, but in WPF it's simple.
Much better databinding
Easier to develop (once you understand the core concepts, which unfortunately will take a while)
When I started looking at WPF, I treated it as "Winforms with Vector Graphics" and ran straight into the side of the learning cliff. The proper way to transition from WinForms to WPF is to take a heroic dose of whatever narcotic you can lay your hands on in order to forget everything you know, then start from scratch.
Seriously though - it's a lot cleaner and easier if you use a pattern such as Model-View-ViewModel. Read more at The Orbifold, this Google Groups thread and Channel9
Then at some point you'll have an epiphany and start databinding everything. Your code-behind will become not much more than a call to InitializeComponent().
Thanks for the post. My company has tons of time invested in WinForms. I can't imagine getting a medium sized application out in 32 man days; our certification periods are months on end and release cycles sometimes yearly or longer (despite sticking as close to an Agile development philosophy as we can), such is the nature of the applications we develop.
I just played with WPF for the first time and found I can get some benefits of WPF in WinForms by using ElementHost. I extended a WPF TextBox, then wrapped my extended class in a Win Forms UserControl and now have a WinForms app using that WPF text box, complete with spell check support.
I'm impressed to see Microsoft thought of this (hosting WPF in WinForms and vice versa), since I really can't see my company moving to WPF unless we can transition over a long period of time; there's just too much invested in WinForms to start again. With my recent experience I may begin to talk to some other developers about my recent experience and see what their thoughts are. I think WPF will take some time getting used to and that seems consistent with other comments.
Not quite a duplicate but you may find this post helpful about the benefits of WPF aside from the new graphics bits.
WPF or WinForms for internal tools?