7

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.

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
BizApps
  • 6,048
  • 9
  • 40
  • 62
  • SO is for specific programming questions. – paparazzo Mar 09 '12 at 02:03
  • I already threw in an answer, but a side note to consider is if the client machines can handle WPF. There are limitations, and you should avoid some things in WPF if the client machines are not powerful enough (for example, heavy animations). – myermian Mar 09 '12 at 02:32
  • Thanks @-m-y maybe we will be creating client wpf Application with less animation. – BizApps Mar 09 '12 at 02:43

3 Answers3

8

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

Community
  • 1
  • 1
myermian
  • 31,823
  • 24
  • 123
  • 215
  • 2
    I, personally, suggest starting your discovery without a framework. While I love all of the main frameworks, until you understand what they're trying to solve, it's difficult to know which is the best in your scenario. – Reed Copsey Mar 09 '12 at 18:08
  • @ReedCopsey: Or, better yet... use a framework and look at the code to understand what it is doing. It's how I did it :) – myermian Mar 09 '12 at 22:50
  • 1
    The problem with that (from what I've seen) is that it's often very easy to think that the approach taken by a specific framework is the "right" one. For example, if you approach it that way with MVVM Light vs Caliburn Micro (both great frameworks), you'll get an entirely different idea of how things should work - neither is necessarily "right", as both approaches have very strong advantages, but also very large disadvantages. If you start with something like Prism, you'll be trying to understand a lot of things that (while very useful) don't necessarily directly relate to WPF at all. – Reed Copsey Mar 10 '12 at 00:10
  • 1
    @ReedCopsey: Yes, I agree. Prism's learning curve is extremely steep. It took me about one day to understand MVVM and about a year to understand the deep corners of Prism. But, the link I posted to the various frameworks discusses their differences pretty well. – myermian Mar 10 '12 at 02:16
  • 1
    @-m-y,@Reed Copsey . Hi for now we will be using winforms and use WPF later...maybe our development manager is correct..he says that we need to catch up for our backlog projects for now and use winforms to catch up for our backlogs projects.He told me to study WPF in my spare time and be familiar with it before using it in our next projects. – BizApps Mar 11 '12 at 23:08
  • @BizApps: Yes, do study it in your spare time because it is well worth the investment, especially if you stick to MVVM. It has a bit of a learning curve to it the more pure MVVM you go, but it's well worth it in the long-term. Doing pure MVVM w/ WPF helps you avoid spaghetti code where you have code doing work it shouldn't and when requirements change you have to hack around existing code to throw in your new changes. The idea of MVVM (Pure) is to avoid all that and be extremely Agile in changes. – myermian Mar 12 '12 at 02:05
4

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.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
3

For those that are reading and wondering "why WPF" instead of Winforms, the answer is that the WPF databinding makes it a heck of a lot easier. MVVM really is just to help you get the most of out of it, but you don't strictly need it.

As someone who is learning just now, I'd recommend just taking WPF out for a spin, open up a project and start doing what you did in WinForms, manually assigning properties and handling events. It will work. But, once you figure out that WPF does this automatically for you, you'll suddenly start to resent the old way, and you'll wind up following the merry path of MVVM.

TJ Bandrowsky
  • 842
  • 8
  • 12