Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

WPF MVVM Using Commands vs. Event Handlers

I like MVVM pattern, once you start using it, you get addicted to it.

I know that in perfect world your View code-behind is almost empty (maybe some code in constructor) and every aspect of View is being manipulated from ViewModel.

But there are times when creating new fields, properties,commands in ViewModel creates more code than implementing same thing in event handler.

At moment I stick to following rule:

If event handler code manipulates very small portion of it's view (for example button click event handler increases font of certain TextBlock that's located on the same view) then it's OK to implement logic inside event handlers. But if View needs to manipulate business logic or access resources that are outside of view, then I assign these responsibilities to ViewModel.

What do You think about my approach?

What do You try to avoid when using event handlers and ViewModel?

What best practices can You recommend when using MVVM pattern?

like image 338
Daniil Harik Avatar asked Apr 01 '09 11:04

Daniil Harik


People also ask

Why should we use routed commands instead of events?

Routed commands give you three main things on top of normal event handling: Routed command source elements (invokers) can be decoupled from command targets (handlers)—they do not need direct references to one another, as they would if they were linked by an event handler.

Why use commands WPF?

WPF adds a more powerful and flexible way to react to user actions using commanding. A command is a self-contained, reusable unit of code that performs some functionality. They do not need to be coded within the window's class.

What is Mvvm command?

Commands are an implementation of the ICommand interface that is part of the . NET Framework. This interface is used a lot in MVVM applications, but it is useful not only in XAML-based apps.

What are events in WPF?

WPF input events are generally implemented as a preview and bubbling pairs. Direct: Only event handlers on the event source are invoked. This non-routing strategy is analogous to Windows Forms UI framework events, which are standard CLR events.


2 Answers

I'd say your rule of thumb is not bad.

In my view, the core concern is "is the code view-specific, or does it address business logic?".

It is OK to have code in the view, if that code is strictly here to modify the view and not to carry out any kind of business logic. Your example of changing a font size is a prime example of code that is perfectly fine in a view (and would increase noise in a ViewModel, making it harder to understand and maintain). In essence, you already do some of that if you use triggers, so it's not that weird.

Keep in mind though, if you use unit tests, it will be very difficult to test that bit of view-logic. If you need it tested, you might be better off putting it in the viewmodel.

like image 140
Denis Troller Avatar answered Sep 27 '22 17:09

Denis Troller


I think I can add thing to the previous comment as well,

Instead of using event handlers, from very modest Experience, Commands give me much more flexibility in the sense that it provides an independent mechanism to respond to events/actions from different controls with the ability to check the status of the command itself.

like image 34
Tarek Khalil Avatar answered Sep 27 '22 19:09

Tarek Khalil