Jaime Rodriguez On Windows Phone, Windows Presentation Foundation, Silverlight and Windows 7
This is part 3 of the 'WPF in Line of Business series' ..
I do recommend part1 (for inspiration from real customer apps ) and part 2 (some of the praises for WPF); this part3 will try to ground WPF as much as possible.
Clearing the FUD
There are at least two myths out there clouding windows client development, so let's tackle that first to start with a clear, less biased view:
Myth #1: Windows Forms is dead.. you should use WPF to build Windows applications going forward.. This is 100% inaccurate. Windows Forms is mature but not dead. As of .NET framework 3.5 (shipped last month), Windows Forms and WPF are both in the framework and in Visual studio so technically they have the exact same support life cycle. Read below for what to expect from Windows Forms coming forward and where to use it.
Myth #2 I have heard or read that for LOB apps I should use Windows Forms.
This advise is well-intended, but a big over-generalization on what the term "Line of business application". I think the people that use LOB in this context are thinking of what I call a "traditional forms over data" LOB application, which consists of controls on a battle-ship gray form; these forms can include advanced controls or charts, and most of these more advanced controls are either the fruit of tedious ownerdraw work, or a 3rd party component bought from a control vendor.
Fair! Those are LOB apps, and there is lots of them out there, but there are also plenty of other LOB apps; for example an advanced or complex, data intensive visualization app ( like Microsoft Dynamics CRM demo or many of the other apps discussed in part 1 and 2 of this series); these are also LOB apps and there is an ever growing number of these too, so when some one overgeneralized LOB term, call it <>.
Once that FUD is out of the way, we move to
Choosing a presentation stack
Begins with deciding if you want a web or desktop application, but I won't tackle that here because this is a WPF series. Let's assume you have chosen to write a desktop application, how do you choose from there? I first try to match on strengths and/or existing requirements:
Overall, I would say is Windows Forms is great for a 'traditional' line of business app; if all your app will need (in its lifetime) is what windows forms has to offer today then that is likely your best choice for the near future -- until our tools get more RAD and our platform is deployed widely-. That said, do learn about all your are giving up ( decoupled UI, richer data binding, styling, etc. and make sure you won't need that later).
Overall, I would say that for line of business applications WPF is the right fit for :
What about Win32 (including MFC/ATL) and DirectX ? This one is tricky for me because I believe in managed code; I think there is some huge innovation ( e.g. generics, anonymous delegates, LINQ, etc..) and I think managed code is getting more RAD all the time (where Win32 might not be as far) but I still have to admit that some scenarios are still better served by 'pedal-to-the-medal' direct drawing of GDI or DirectX on the screen. I also acknowledge that there are products ( e.g. Office, or say AutoCAD, that would be too hard to re-write from scratch, so in my mind we will continue to have Win32 applications for a very long time ... You should expect what you already know is there.
Overall, if you are using Win32 today for one of these big reasons and you might need to continue there; if you are re-writing a win32 app, then consider managed code if your perf requirements allow it.
OK, now that you understand the strengths, and requirements for each technology:
MIX & Match (WPF with what you already have, aka the 'interop scenario' )
For those of us who live in the real world; you likely have existing windows forms code or you need a Win32 optimized app but also want to take advantage of WPF; this is not a problem.
What about mix & match for a new app?
It does work, but WPF and Windows forms is two (different UI) skills, so you might want to make sure the overhead and having to code to a common denominator makes it worth it for you. I have learned from customer experiences that on new apps, mix & match works for scenarios where you intend to write a large percentage using one technology. For example, in my world of "large suites of applications" if the split is not a 80-20, you are likely not taking advantage of the either platform in full. If you are creating a new app, you will make architecture decisions ( e.g. localization, styling, resources, databinding, windowing framework, etc.) that need to be consistent across the board, if you have 50-50 splits, that is two ways of doing things or a big abstraction layer that implies work for you , run-time overhead for the app... so for me a mix & match (aka interop) approach on new apps needs to be justified..
The two common scenarios for a good 80-20 is:
OK, now the hard choice: is WPF for you??
PingBack from http://crm.discoveryjournal.info/2007/12/18/am-i-ready-for-wpf-do-i-need-it/