Why to Jump to WPF for Business Application instead of using Winforms

Question

Our team is experienced working on Winforms and ASP.net projects.

As what other programmers in programmers stack exchange recommend me to jump to WPF for our team next projects instead of using WinForms for our Client based business Applications.

Now i am starting to Develop my first project using WPF, its a little bit tricky for me as its my first attempt to use this.

Can you gave much deeper information why we need to jump to WPF instead of using winforms?

I need to convinced our manager that we can dig on WPF for our client based projects.

We are using VS 2008.

Answer 1

1. Pick up a good MVVM Framework. I personally use Microsoft Prism. For other alternatives, look at this StackOverflow question.

2. Routed Events are for the view only. For example, if you want to scroll to the end of a multiline textbox when the text changes.

3. Commands are used to bind events in which the logic resides on the view-model (business logic)... For example, a submit button.

4. If you have designers on your team, get them to start playing around with Expression Blend and understanding styles/layout. Expression Blend allows you to use sample data to see your applications layout without having to run it all the time.

5. Understand The difference between ContentControl and ContentPresenter.

6. Understand how ItemsControls work. There is a difference between SelectedItem, SelectedValue, and SelectedValuePath.

7. Look at a lot of exmaples online. Dr. Wpf, WPFTutorial.net, Josh Smith on WPF, etc.

8. If you plan to take advantage of Code UI Testing (to test the actual User Interface), then make sure to name controls that matter (most MVVM tutorials tell you that you shouldn't have to name any controls). If you don't plan on doing Coded UI Testing, then don't name your controls unless you need to reference them from the view itself.

9. IValueConverter and IMultiValueConverter should only be used to convert properties to view-related items. The most commonly used converter is the BooleanToVisiblity converter.

10. TargetNullValue, FallbackValue, and StringFormat are important when using binding. Don't make assumptions that the data being bound will always be available and correct.

11. You will almost always expose ObservableCollection<T> or ReadOnlyObservableCollection<T> from your view-models. Very rarely will you ever return any other type of collection, including an IEnumerable<T>.

12. Be careful in choosing your BindingMode: OneWay, OneTime, TwoWay, OneWayToSource (WARNING: OneWayToSource is tricky... it still requires a getter because it is not a write-only binding).

13. A good debugging tool that is free is Snoop. It is similar to a DOM explorer for a running WPF application. A more advanced (and not free) tool that is a bit more powerful is Mole.

That's all I can think of for now... Oh, and if you run into road blocks, StackOverflow is your friend :)

Answer 2

I wrote a series on WPF with MVVM specifically targeting developers who have a Windows Forms background, and are planning to jump ship.

It walks through some of the basics of WPF, showing how it allows you to approach your development differently than Windows Forms, including introducing (gently) templating, commands, and other concepts that tie into the vastly superior data binding in WPF.

This would provide a nice introduction to WPF, and show you why it can be better for business applications than Windows Forms.