CODEWITHSUNDEEP
c#wpfmvvmicommand
Noah Roth
Noah Roth

Reputation: 276

Do you have to use commands to follow the MVVM pattern?

I am in the process of learning and understanding the theory and usage of the MVVM pattern used in WPF programming.

Coming from WinForms, I still have that tendency to just double-click a button to bring me to the clicked event handler.

Reading online about MVVM, apparently this should never be done, because, well...I'm not sure. It is suggested that one should utilize the ICommand interface to encapsulate actions that are invoked by the UI/View.

I have yet to read why this is preferred. If you use event handlers, you still aren't breaking the View/ViewModel relationship, because the ViewModel still knows nothing of the View...right?

Will using commands provide some extra flexibility that event handlers don't offer? If anything, I feel like using commands will make the code a bit more mangled in the sense that you have to backtrack to find the ICommand logic. With event handlers, it's all right there in the code behind the View. Am I missing something?

So, essentially, does using event handlers instead of commands violate the MVVM pattern?

Upvotes: 1

Views: 185

Answers (2)

Peregrine
Peregrine

Reputation: 4546

It really depends what you want to do on the button click.

If you just want to interact with the U.I. (e.g. changing the visibility or other property of a control) then only the die hard MVVM purist would oppose this.

However, if you want to do anything relating to the model or other data, that would go against everything that MVVM stands for in terms of separation of concerns.

Upvotes: 1

Fede
Fede

Reputation: 44028

With event handlers, it's all right there in the code behind the View.

This is precisely what you MUST avoid.

Your application's logic (or even worse, your business logic) does NOT belong into the UI and should never be placed in code behind. This is why ViewModel commands exist.

Naturally, if your button fires an animation or does any other UI specific task, then yes, it makes sense to handle the event handler and put that code in the UI.

And yeah, if you come from winforms, doing proper separation of concerns and avoiding intermixing the UI and the rest of your application might seem a little involved at first, but it really pays off once you understand how this helps produce very clean code, and how the UI can be 100% customized without having to change a single line of code in your app's logic.

Also, your sensation that

you have to backtrack to find the ICommand logic

is also due to your winforms background, where your attention is put in the UI and you reason about your code in a UI centric manner. In WPF, the UI is the last thing I usually build, because it's just a self-evident manifestation of the data and logic that I already built in the form of Models and ViewModels. My attention is not put in the UI, but in the actual data and logic that my application deals with.

This means that I don't spend a lot of time looking into UI specific classes, for anything other than UI specific matters such as animations and interactivity.

Upvotes: 4

Related Questions