Why use commands in WPF and not event handlers

Question

I am using WPF like a year ago and MVVM, I guess not full, because I don't use Commands,. and till now I really did all I need without commands and it works fine, but the most important thing to me, its clear and short, the theory of MVVM says no code behind, but, why got complicated with 1000 classes, one for each button or event?

I really don´t see the gain. Is this only conceptual or there is more ?

Answer 1

I'll try to explain why commands are useful.

In MVVM, the View developers (designers) are supposed to do only things that affect how the program looks like, while ViewModel developers (programmers) would only care about the behavior.

Imagine you have a form with a submit button. If the form is not submitted to the database(for example), it is the programmer's problem; no one would blame the designer. However, using event means that everything is done at the View side.

This is where Command comes to the rescue. It allows the programmers to do the logic, thereafter wait for the designer to bind to it. Programmers can do unit testing without the design (View), and proudly tell people that it works. If it breaks, that means the designer did not bind to it correctly.

Of course, I believe there are many people here who would be doing everything alone. In this case, the usefulness of MVVM would be reduced. However do note when you totally remove all views from the VS project, your ViewModel is going to compile and be fully functional - except that there is no GUI, and that it can receive no user inputs. Typically, most of the project requirements are behavioral, so if your ViewModel are working, then you would have met most of the requirements.

Lastly, I would want to point out that, it is okay to have code-behind - as long as it is purely only affecting how things are looking, and not affecting behaviour. Of course, most perfectionist would want to have zero code-behind, but in some cases this isn't always possible.

Answer 2

Your question is too broad to be answered in a line. But I am answering it since I have been working with MVVM for quite a long time by now and also have worked in WPF without MVVM also.

As the comment points out your words : The theory of MVVM says no code behind nope why got complicated with 1000 classes, one for each button or event.

These are not true actually. Because there are lot of benefits of using MVVM and that is the reason why this question is too broad.

I am surprised to hear that you haven't used Commands till now and you're using MVVM. Because command is a major part of MVVM. The main benefit of using MVVM is that it really helps us to

1. Separate the view and model. Nobody wants their codebehind(YourPage.xaml.cs) to contain all data related code, data manipulations, designs and also setting the user control data and so on. It will make the situation worse if you want to fix a bug in your code or someone wants to review it. In MVVM, you can have a clean code behind. There is not much difference between an event handler and command. But if you want to update several views over a button click, MVVM could handle it very neatly and easily.

2. Databinding ensures better maintainability and readability. Instead of setting TextBox1.Text = "Hello World", you could bind the Text property to a view model property and let it update each time the model changes. This is really a great thing to have. Who wants to write code for updating the view each time model changes. Think how many lines of code are saved now. Everything is done by databinding. If you want to change 10 textboxes content when a button is clicked, binding will be very handy. Hence it reduces Tight Coupling.

3. Testability : The developers can create unit tests for the view model and the model without using the view. The unit tests for the view model can exercise exactly the same functionality as used by the view. Also many developers can work with the same product at the same time, since a large view could be split into smaller views and work could be divided very easily.