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.”
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.”
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.
Rachel Lim's Blog 
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
I know this is a rather old post at this point and I’m waaay late to the party. But it is a misnomer to say “WinForm programmers struggle”.
A better phrase would be “un-disciplined programmers struggle”. I say that because there is nothing about WinForms that prevents a programmer from using MVVM and MVVM wasn’t invented alongside WPF.
I’ve been designing my apps using MVVM since the late 90’s when I was still doing VB 6 apps. The fact of the matter is that regardless of the technology or language being used you will have programmers who employ best practices and those who don’t.
The ones who struggle are those who never used those best practices and moved to a technology that strongly enforces certain design principles (i.e. WPF enforcing an MVVM approach). But there are plenty of us who moved to WPF and it wasn’t a struggle at all. Quite the contrary, it felt like a homecoming 🙂
Hi guys I am new to windows forms and also WPF sorry if my question is noob….I wanted to create effects like that of windows 8 tiles and transistions and the rich UI like in windows 8 but i didnt how to do it when i googled it told me that u can metro styles which provide windows 8 kind effects..How can i do it..?? neither do i have much knowledge in windows forms nor in WPF so please help me out..Which one should i start learning..?? Should i start with WPF or Windows Forms…???
You’ll probably want to start researching WPF Animations for these kinds of effects 🙂
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.
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.
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.
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.
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.
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
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 =)
Hi, Rachel! Unfortunately, in real world it’s not so simple…
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 =)