-
-
Categories
-
Archives
-
Services I use
-
Talkr: Letting blogs speak for themselves.
Sep
5
WPF vs. Windows Form - Additional Point
September 5, 2007 |
This has been a question on my mind since I first heard of WPF and Josh Smith(MVP) who seems to be locked in and on the ball when it comes to WPF began a discussion today - WPF vs Windows Forms - I thought I would jump into.
The question, which is the basis of his post, was asked of Josh during a presentation of his, which was:
“I work for a bank’s IT department. We build Windows Forms applications which basically just show large tables of numbers, allow the user to sort them, edit them, etc. There is some simple business validation in place, and a few other standard LOB-application things you’d expect. We have no need for UI candy, animations, 3D, etc. Why should we use WPF and what can I say to management to convince them that we should use WPF in upcoming projects?”
short version:
“How does WPF make sense to business? And how do you convince management that it is a worthwhile tool to move to?”
Josh goes into some detail and covers some of the key points of areas where WPF does well and where WinForm is still the platform of choice and he gives reasons around this including:
- WPF is not intended to completely replace WinForms (I was unclear on this so thank-you Josh)
- WPF is a great platform for rich media applications, skinning applications and WPF’s binding is much more advanced that WinForms
- Additionally he states, and this is more important than some businesses realize, that WPF is new; thus exciting, which is important when trying to retain and keeping employee interest - the more driven your staff is to learn and improve the more important this is in my opinion.
- If you have a codebase which would not benefit from the features of WPF then moving to a new platform from a tried and tested platform; there is not much point.
These are all great points and he doesn’t push you to WPF but gives the facts of where WPF is useful and excels, I applaud him for this. However one other item which is unlisted but would be a major business advantage is that with Windows Presentation Foundation Browser-Hosted Applications and Silverlight(code-name WFP/E; E was for everywhere), which was officially released today, there is a transition process (I am inexperienced with how streamlined this is as have not executed for a business application as of yet) in which enables developers to move WPF application into Web Browsers - which is currently not well - if at all - supported by WinForms. Finally with Silverlight opens up cross browser access as the Browser plugin is cross brower as well as cross platform.
This advantage alone would be enough to sway many corporations to investigated WPF further - if even on a prototype level to start.
If someone has an article or preferably a (simulated) real-world application which they have executed either of these process(WPF to WPFBA or Silverlight) on I would be very interested in information on how the process went and if there were many obstacles/road-blocks/required ‘hacks’. If I get time I would like to do this myself but if someone has done this it would save me some time =).
Thanks again to Josh for starting this conversation and his thought out answer. You can get his articles via RSS - worthwhile if you are interested in WPF.
Additional information:
Listen to this podcast
Comments
2 Comments so far
Thanks for the nice critique of my post.
I am not sure how relevant and useful XBAP will be in general. Since it is currently limited to running only in IE6 and 7, it has no applicability outside of a corporate intranet deployment scenario.
Within that limited usage context, it’s primary “advantage” is the fact that the XBAP deployment model is quite similar to a standard Web app. However, the fact that WPF desktop apps (not XBAPs) can be deployed via ClickOnce, I’m not sure how much benefit XBAPs actually proffer. Also keep in mind that by default XBAPs run in a security sandbox, which limits what your app can do.
I am yet to read or hear someone explain how deploying their application as an XBAP resolved some overarching problem(s) they faced. I’d love to find out what those problems are and why XBAP was the silver bullet.
On the other hand, I wouldn’t say that Silverlight and WPF are really that closely related. Mentioning them as two sides of the same coin is dangerously misleading, particularly considering that Silverlight v1.0 is only programmable in JavaScript!
The functional areas in the Silverlight platform are a substantially reduced subset of WPF. I don’t expect Silverlight to really catch on until folks can use it from the comfort of a managed language, like C#.
What I’m getting at is, in my opinion WPF is a *desktop* application platform. Silverlight, a cousin of WPF, will eventually be able to cover the Web side of the house. But I wouldn’t say that using WPF will solve any problems which Web developers face.
Thanks for the toughtful reply Josh!
I agree that XBAP is not what it could have been. However it does still hold some weight for many companies for intranet applications which many WinForm/Web applications are built for. I have no direct experience with XBAP but this is my current understanding that it is a fit for the intranet enviroment. In many scenarios architecturally it makes more sense to develop WPF/XBAP applications vs creating WinForm application and then duplicate this application, more likey a portion of, in web(html/js/server side). I have seen many companies implement this winform/web structure for a wide variety requirement reason. In the end XBAP may not be a “silver bullet” but if would be more efficent to develop this combination rather than the other that I mentioned above.
Regarding Silverlight I should have clarified that I was speaking of the match between WPF and Siverlight 1.1. With Silverlight 1.1, currently Alpha, it is my believe and understanding that WPF/Silverlight applications could be build side by side with some overhead but much less than other options for the desktop/web space.
There are other items which Silverlight addresses which would be benificial to development teams including:
Consistent development enviroment for desktop and web applications - including consistent access to the same web services.
Remove the requirement to developers have knowledge of javascript - I have seen many developers not be able to grasp this language
Reuse of general codebase (Internal framework)
One note you made that I do disagree with is:
In my opinion Silverlight opens up the door for more web developers who are comfortable with .net and not javascript/ajax/html where they can leverage the knowledge they have, with Silverlight, to hit the group running. I would say that having developers stay abreast with WPF/Silverlight is much more contained knowledge space , and cost effective for business, than WinForm-WPF/ASP.net/AJAX/HTML/Javascript.
My main point however to answer the original question is that if a company is going to invest in development with Silverlight then this would be an argument towards using WPF as well do the “cousin” relationship.