次の方法で共有

Am I ready for WPF.. do I need it??

  • [アーティクル]

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: 

Windows Forms:

  • Windows Forms is mature, well tested, and the software requirements is .NET Fx 2.0 (a widely deployed framework), where WPF requires 3.0 ( new version of the framework, ships on Vista, but needs to be downloaded to earlier OSes).
  • Windows Forms has a good set of controls, including a rich, editable data grid.  WF also has a well established ecosystem with a lot of 3rd party control vendors, a lot of trained developers, etc.
  • The tools for building Windows Forms applications are very optimized for Rapid Application Development (RAD). Features like drag & drop data binding, tools & processes for localization are the standard.
  • The only negative for Windows forms is that 'it is what it is'.. you should not expect Microsoft will add styling or animation, hardware acceleration, or any of the other of the WPF goodness.  

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).

WPF:

  • More details on the goodness of WPF was covered in detail in part2 of this series, here is a summary:
    • richer user interface that integrates  UI (controls), graphics ( 2d and 3D), text, animation, rich data binding -at run-time, though tools are not as RAD for data binding -.
    • Great foundations for decoupling of UI logic from business logic, easier to create very customized user interfaces with out resorting to a lot of OwnerDraw code..
    • Vector graphics, hardware acceleration, composition engine, truetype, etc.
    • Declarative mark-up (XAML) exposing new tools for designer and a new workflow that for designers and developers to collaborate in the software creation process, etc..
  • Some of the 'weaknesses' for WPF in LOB apps are
    • It is still missing a few controls that are common in LOB apps (e.g. datagrid) .  Some of these controls are available from 3rd party if that works for you. Others are available as samples from Microsoft, and rest assured we are looking to invest in the platform to fill-in the gaps.
    • The WPF designer in VS 2008 is not as RAD as the Windows Forms designer (you can't do this incredibly RAD data-binding for example, but I hear from customers not all of them use those features, so this is a variable factor).
      An arguable helper in the tooling space is the Expression tools; Blend compliments VS very nicely, and you get seamless integration via shared project system, but it is still two tools and for a traditional LOB it is likely still not as RAD as just Windows Forms designer.
    • The need for new skills, and ramp-up.  WPF is new so you will have to learn it; we are still early on (or have not started but will soon) sharing best practices, lessons learned, etc.. so expect a few curves if you get started; nothing major, hit the newsgroups, there are a lot of resources online, etc..  you are early
      • Under skills, I do want to highlight that if you go into WPF to create a richer experience, you will need a designer's eye on the team; with WPF you have all the flexibility (styling, templating, triggers, animation) to create a richer experience than you could before .. but very little of it comes in the box..  the default themes for controls still look like windows controls, so don't expect round buttons with gradients unless you are willing to do 10 clicks in blend to style the controls...

Overall, I would say that for line of business applications WPF is the right fit for :

  • Apps that aim to deliver  a great user experience ( rich visualization, styling/branding, 3D, text (or documents), hardware acceleration, etc.. )
  • Big, long-term investments for applications that will grow over time and can take advantage of WPF's architecture (but be prepared for a slight learning curve so you know how to take advantage of the platform)... 
  • Applications that can benefit from XAML across platforms (and/or deployment paradigms);  if you are creating a great app for the desktop but think you might need to deliver a thin subset over the web, then silverlight and XAML might drive enough reuse for you.

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:

  • a few of you hopefully are thinking I am OK with Windows Forms or Win32 and will stay there.
  • a few of you bailed on requirements (.net for windows forms, .net 3.5 for WPF, etc.)
  • some of you are thinking WPF sounds good long term,
  • and the rest of you are thinking "I can't throw away my investment", so let's add an option for those who need to preserve your investment:

 

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.

  • You can host WPF inside a Windows Forms app and seamlessly go back and forth..  The only gotcha is "airspace", which is not a big limitation as airspace is an 'existing' issue on legacy technologies
  • You can host WPF inside a Win32 app and go back and forth ...
  • You can do the reverse and create a new WPF app that hosts existing components ( win32 and/or Windows Forms )..

 

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: 

  • Windows forms app with islands of WPF richness or
  • WPF apps reusing a few Windows Forms controls ( like grids, or complex charts ).

 

OK, now the hard choice: is WPF for you??

Comments