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.

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

  1. Aaron Gasaway says:

    Old post, but i’m just now seeing it.

    I think this article summarizes the essential difference between MVVM and Winforms very nicely. It also points out why so many coming from a Winforms background have trouble with WPF. Most of the code examples out there are MVVM-oriented in nature, and MVVM assumes a division of labor (or at least process) between building the UI controls and the data objects they display.

    Unfortunately, in the business world, there is rarely such division of labor between creating the UI and the data. I know plenty of app developers who develop GUI’s and program, but don’t know a single graphic artist that develops GUIs without programming. I’m sure in the world of video games and sleek commercial gui’s, there are some.Yet in the world of finance & insurance I inhabit, there are next to none.

    My world is where the majority of devlopers live and toil. As I write now in the first part of 2015, WPF is still firmly the platform of choice for desktop LOB apps or those deployed to a Citrix server. Few in the corporate world feel comfortable with greenfield winforms projects; Win RT/Metro is not an option and won’t be for some time (businesses are slow to adopt new versions of WIndows—especially ones like Windows 8 that mean a big change for users).

    What would be nice is if some of the XAML crowd that champion MVVM also opened their eyes to the needs of the majority of businesses. It’s a crowd that Winforms and ASP.NET seem to respect and cater to. By comparison, I could not, for example, locate a single complete, functional example of two-way binding to a WPF datagrid with dynamically-generated columns.

    Is that just not possible using MVVM? If not, what good is MVVM to businesses such as mine? ‘Name’ and ‘EmailAddress’ will nearly always be coming from database fields; hardcoding them as string properties on window-by-window basis seems not only overly time-consuming, but a maintenance nightmare..

    Sorry if this comes across as a rant—it’s not meant to be. I’ve found your articles to be some of the best and most accessible for WPF newbs like me. It’s just frustrating to hear MVVM preached in every post out there, and the old Winforms approaches villified, and then not find a single MVVM solution that seem to address the most fundamental needs.

    Regards,
    Aaron

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

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

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

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

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

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 124 other followers

%d bloggers like this: