Understanding the change in mindset when switching from WinForms to WPF

One of the biggest hurdles I find WinForms developers struggling with when learning WPF and the MVVM design pattern, is understanding the shift in thought process that is used for WPF/MVVM development.

Here’s the best way I can summarize the difference:

  • In WinForms, your forms and UI objects are your application.
  • In WPF/MVVM, the class objects you build are your application, while UI objects are nothing more than a user-friendly interface for interacting with your application objects.

Example

For example, suppose we were asked to make a simple Registration form that takes down a user’s Name, Email Address, and asks them if they want to receive Special Offers or not.

A WinForms developer’s thought process might be to think “I need a Window that contains a TextBox for name, TextBox for email, CheckBox for if they want special offers or not, and a Button to submit the form. When the Submit button is pressed, the data is taken from the UI objects, and saved to the database.”

Winforms Developer's Thought Process

In contrast, a WPF developer’s thought process is “I need a Window that contains a RegistrationForm object. This class needs a string for the Name, a string for the EmailAddress, a boolean property for if they want special offers or not, and a Command to submit the data.”

WPF Developer's Thought Process

But of course WPF doesn’t know how to draw a class of type RegistrationForm, so we’ll have to tell it how to draw the RegistrationForm object using a Template. This template would probably render the Name and EmailAddress properties using TextBoxes, the IsSpecialOffers property with a CheckBox, and provide a Button to run the SaveDataCommand, although that doesn’t have to be the case and is something that can be figured out later.

With WPF, the UI layer and the application layer are so completely separated that you don’t actually need the UI layer at all. If you wanted, you could run your application entirely by test scripts, or through a console window. The actual application layer never needs to reference any UI object to get its data.

Using this concept on a larger scale

In fact, this thought process is used on a much broader scale for the entire WPF/MVVM application.

Want a LoginWindow to come up, and on successful login switch to the MainWindow? No problem, simply start the program with your LoginClass, and on successful Login return the ApplicationClass.

Want to have an application with separate Windows for Products, Orders, and Customers? No problem, create your ApplicationClass to hold a List<T> of available “Window” objects containing the classes representing each “Window”, and include a SelectedWindow property which identifies which window object is currently active.

Of course, WPF needs to know how to draw these class objects, so you’ll need to tell it to use a specific DataTemplate, UserControl, Page, or maybe even Window when rendering these objects.

Summary

This is not meant to be an in-depth look at how WPF is different from WinForms or how to switch from WinForms to WPF, but is more of a brief summary on the change in mindset needed when moving from WinForms to WPF.

With WPF, your application consists of the objects you create, and you use DataTemplates and UI objects to tell WPF how to draw your application components. That’s the opposite of WinForms where you build your application out of UI objects, and then supply them with the data needed.

Once you grasp this key difference, WPF becomes much easier to understand and work with.

9 Responses to Understanding the change in mindset when switching from WinForms to WPF

  1. Hi, Rachel! Unfortunately, in real world it’s not so simple…

    • Rachel says:

      Hi Michael,

      You’re right, the real world is not nearly as simple, however once you understand the different thought process used with WPF & MVVM, it becomes much simpler =)

  2. Michael Rushton says:

    Well designed Winforms applications can use MVP, a predecessor to MVVM. So the “thought process” can be the same whether WinForm/MVP or WPF/MVVM

    • Rachel says:

      Its true, but not everyone knows MVP and I think MVP still has to directly reference UI controls, which is something you don’t need to do with WPF’s binding system.

      I like to answer WPF questions on StackOverflow and see a lot of developers there struggling to understand WPF because they’re stuck in a WinForms mindset, so this post was mostly written with them in mind =)

  3. The big advantage I see to using WPF and MVVM is that the view-model is actually unit testable! You can test the behavior of the view-model without even creating a view yet. You can even execute your ICommands because those are public properties on the ViewModel.

    Thanks for your help on SO, by the way.

  4. Adolfo Perez says:

    I agree with you, the powerful WPF binding mechanism is what makes this UI/Business Layer separation possible. I have developed many WinForms apps in the past, some using MVP pattern and still found it very limited and troublesome. However, the transition to WPF is not that easy, the first big challenge is, like you said, is start thinking the WPF way.
    Another problem i faced is understanding all the things happening behind the scenes like bindings, style inheritance, event bubbling, etc.

  5. John says:

    I’ve been working with MVVVM for a few years now, and I still don’t see the big ‘why’ of it all.

    Writing business logic modular and independent of UI has been easy for decades. I’ve always been able to do it in Windows and Unixes without any trouble in languages from C to Java and C#.

    My impression of MVVM is that it is extra froth, 3 files for every 2 that did the same thing the old way. Terms like ‘separation of concerns’ are presented as if they are new ideas, when modularity has been a rule of good programming since 1970.

    • Rachel says:

      Hi John,

      The big advantage is how separate the UI and the application are. You can have a team build and test the entire application without the UI at all, and you can have a UI design team build the entire UI without the application data.

      Separating data from UI isn’t a new concept, however with WPF’s binding framework, it makes the separation much easier. MVVM is an easy way to understand and work with that separation.

  6. Sangram says:

    After spending 3 years in Winforms and now a beginner in WPF, it’s quite confusing for me to understand how this mvvm model works.

    Person who has not worked in Winforms may understand it quickly because every damn i try to do, i tend to think like a winform developer. :/

    Thanks a ton for this awesome article.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 109 other followers

%d bloggers like this: