WPF for Business Applications, ready for the average user?

We're starting a new project and naturally we looked at leveraging the latest .NET framework features (auto properties, extension methods, lamdas, LINQ, etc.). The question of user interface came up and we had some decisions to make.

This specific project we looked at building one client web front-end (for the majority of the users) and a SmartClient for a smaller contigent that requires a little more real-time feel along with more rich features the web client might not be able to do (without a lot of heavy lifting). As we were looking to start things, the notion of WPF vs. WinForms came up. This led us down a path to look at Prism (the Composite WPF project from the Patterns and Practices group) which has a lot to offer in frameworks and being able to do more with WPF (Prism is WPF only). WPF also has some benefits to automation (there are some new products that are tying into the automation frameworks) and testing. The pretty UI is just an afterthought and not the focus since we're building what would be considered a "traditional" business application (forms and maybe grids and reports).

WPF also has the advantage that we could deliver the application using xbap which kicks ClickOnce up a notch. The Prism framework is based on modules loading into XAML regions so we were even looking at re-using XAML user controls and plugging them into different clients.

This has kicked off a bit of a controversy and discussion. Is WPF really suited to business applications? Of course the answer is (as always) it depends. If you're business application requires a rich UI and a visual paradigm, then the obvious answer is yes. It's more intuitive for a user to drag a part from one component to another (say in a room designer) than to pick items from a grid and enter values in a form.

However for the larger business applications (the meat and potatoes of the corporate world) we don't deal with "rich UIs" so where does that leave you? WinForms is not dead and according to Glenn Block is the "recommended breadth solution for LOB application development in the foreseeable future". The trade off is that if you're building SmartClients you might look toward a framework that provides a lot of OOTB features that you don't have to do. I'm not a big fan of NIH syndrome and the idea of having to rewrite loggers, event handlers, aggregators, presentation models and everything else you build into a SmartClient. Frankly, I don't get paid to build frameworks or re-invent the wheel for every application my client wants.

Prism provides a nice framework (IMHO CAB done right) that you can leverage and pull it out in piecemeal to what you need. Unfortunately, it's WPF only. While some of the principles can be carried over to WinForms I think you'll end up doing more work to say try to get DataBinding working the same way (if at all). There are other aspects to WPF (ignoring the pretty UI) that don't carry over to WinForms (routed events, event aggregation, etc.) all of which you have to build yourself (or use CAB which is the overbloated bazooka edition of WinForm programming).

The word from my twitter folks is somewhat slighted toward WPF:

  • WPF databinding isn't as evil as its predecessors and some people wouldn't build a WPF app without it
  • Control templating and eventing in WPF is useful even for the basic forms and datagrids
  • Testable automations ARE good reasons to use it

Other questions that come up:

  • Do you really need/want a separate designer to build your UI and keep it completely separate from your application code? In WPF this is easier. For WinForms you need to outfit them with Visual Studio and frankly, I've never used a designer on a WinForms project (I have on WPF ones, but not business applications)
  • What is the adoption from the user perspective and can you get them to think "outside of the form" and be creative with solutions. In WPF you're not as bound to traditonal approaches to visual problems and building the same solutions is somewhat easier (trust me, manipulating pixels in WinForms is a bugger to put a control on top of another one, in WPF it just works)
  • Can you bake the learning curve of WPF into a business application budget or should it be something that developers just know? (i.e. only start a WPF app when you have developers that know it inside and out, which few do these days)

I’m on the fence on WPF. From an automation and programming model, I think it’s fathoms above WinForms. I don’t mind the crafting of a good looking UI as I’m used to it in Blend and can whip off a UI just as fast as I can with WinForms. However I’m not sure its worth the extra effort (is there extra effort) in building business applications with it, but I’m torn with xbap where we can deliver a rich user experience without having to install a client.

For WinForms you generally have to either harvest what you have from existing applications or RYO when it comes to the application framework. Re-writing presenter base classes, validation strategies, various implementations of patterns like repository and specification, and building a service layer over things like NHibernate can be fairly straight forward but still might take a few weeks, weeks of cost that the customer doesn't want to pay for to see nothing out the other end.

There is the build as you go model, which works for any technology however you do want to keep consistency when you're building 5+ large applications a year and there's turnaround in the IT department. Re-inventing the wheel for every application isn't an option for anyone.

Feel free to chime in with your thoughts, experiences, and ideas. Thanks!


  • Hi Bil

    Nice article. Two points I would add.

    1. On the Winforms being the breath solution, this is changing. Tools are maturing, and with the next version of VS the investment in WPF is signficant. Also with Prism we've aimed to reduce the curve of building business apps NOW. In the development of the RI the Prism team itself became true believers in WPF as an LOB platofrm. This story is going to get better and better.

    2. On Prism + Winforms. There are alot of capabilities in Prism that are not winform specific, as we built them as such. Particularly the module loader is agnostic, and actually the event aggregator IS agnostic. The CompositeWPFEvent that we ship for EventAgg is WPF specific as it relies on the WPF Dispatcher for threading. However, the EventAgg only depends on a base event class that is NOT bound to WPF. You can implement your own WindowsEvent and use it with EventAgg out of the box. We also split the projects into two, so you can grab just the non-WPF project (Composite) and leave the rest. Brian Noyes I believe is going to be adding a WinForm version of the event base to the contrib project.

  • I am building an app in WPF at the moment. I could have done it in Winforms, and that would have been easier given my current knowledge of WPF. But the app is all about presentation, hardly any business logic, so it made sense to try and learn more about WPF with this app.
    I think that WPF, or whatever it evolves into, is how Microsoft sees the future of thick client applications. And the line between a desktop app and a browser app has definitely become blurred. Probably a good thing.
    I am using the June2008 preview of Blend and it certainly helps. I also think you need two monitors, one displaying Blend and the other displaying Visual Studio. At least that's how I have it set up and it really helps.

  • WPF's questionable text rendering prevents us from doing anything with it.

    Customers have already asked us to fix 'ClearType' for them, because it makes the text fuzzy. WPF doesn't even use subpixel rendering if ClearType is turned of so text there will in fact be less sharp no matter how much you like 'ClearType'. Font's are smeared across more pixels, using greyscale, making everything look significantly worse than just plain old razorsharp but jaggy text.

    For a business applicating showing a lot of data we are forced to present our clients with the most readable applications, which is anything but WPF.

    So far there's no sign of Microsoft of fixing this issue, event though it's clearly a problem not only to us. Apparently the core rendering engine for WPF is built in a way that doesn't allow pixels to stick to the grid of a monitor.

  • "This specific project we looked at building one client web front-end (for the majority of the users) and a SmartClient for a smaller contigent that requires a little more real-time feel along with more rich features the web client might not be able to do (without a lot of heavy lifting)."

    Out of interest, did you consider using Silverlight and just having a single app?

  • >>>The pretty UI is just an afterthought and not the focus since we're building what would be considered a "traditional" business application (forms and maybe grids and reports).

    I ----completely---- disagree about "pretty ui" and how we should not care about that.

    So many developers underestimate the importance of a "pretty UI". One argues the business doesn't care but I can guarantee you it helps the business. Why? because people tend to be visual right. Not just functional, especially on the internet. A dull boring and depressing UI with no bling to me makes life boring. A good UI with great CSS can make even functional requirements stand out and seeing something that has better curves, borders, even nicer buttons makes the page flow and easier on the eyes.

    That's something developers and managers SHOULD think about. I do not believe it's JUST the functionality because visual appearance is a part of this for the user experience. Why do you think sites like twitter are so addictive? It's NOT just the functionality. It's the entire user experience and even for internal business apps, I can't argue that this should be any difference...as I believe all internal web apps must have a BL regardless of the Size for reuse of code to save the business money and developer time.

    point is, developers SHOULD care about look & feel. It's not just for the graphic artists. you should look at it as part of the flow.

  • >>>With all these advantages over WPF, why would anyone pick WPF? IMHO only because it's 'new'. And that's exactly why people should be careful.

    People do not typically pick things just because they are "new". That's a blanket statement and a naive one unless your intern or "fresh out of college" newbie on your team is ranting and excited about something. If you have been a programmer for 5+ years that statement is not true.

    For instance, when pushes for using the .NET framework 3.5 with SP1 (which by the way really isn't that NEW anymore by today's iterations), immediately management figures oh, "it's just a naive excited that the developer wants something new and he isn't thinking about the business impact". Do you think that most developers WANT to move to a new version of something simply because they see it is "new" and see it as a benefit to themselves only? Of course not, not usually. Not at all. They most often have done pretty extensive research I find, and usually and have pretty good reasons typically to do so.

    Now moving to something like MVC Preview for your production environment that is not even finalized by microsoft to me is naive. That's something bleeding edge. Using something like WPF which has been official and out for some time now is NOT.

    If management asks you why, and you give them 10 solid reasons and how it's gonna help the business and that manager concludes by smiling and saying you're a bit too excited about it...then that also is naive. Maybe that manager should put down the "new" guard and try some new things for a change in his/her environment if the developer or team is that motivated.

Comments have been disabled for this content.