1

I have a similar question to THIS

Why and in what circumstances should events be avoided( and commands are prefered) when developing WPF apps? I'd like a PRACTICAL example where the event way becomes too hard to follow/maintain (that's my main interest).

Community
  • 1
  • 1
Andrei Neculai
  • 472
  • 2
  • 5
  • 21
  • How is this really different from the question you're referencing? Events are just code behind - those exact reasons apply. – Reed Copsey Jul 10 '13 at 17:31
  • Its not that its hard or difficult to maintain in the code behind. The main use of MVVM is to completely decouple UI from the business logic , so in case of events if you have some BL to be executed you can well go ahead with using Commands for events . For eg consider that when an event occurs you are changing the 'background color of any control' then you can do this in the code behind itself since it doesn't have much of a business logic (still you can achieve this via Command) . It also depends if you really want to unit test this scenario then go for Command else go with code behind. – srsyogesh Jul 10 '13 at 17:38
  • Because of the decoupling you can unit test the software very well if you have everything in Viewmodel or Model rather than in View. – srsyogesh Jul 10 '13 at 17:39
  • If the linked article didn't help, this is probably the only thing that will. http://msdn.microsoft.com/en-us/magazine/dd419663.aspx This is written by Josh, and It has your requested example. After you dig through it, you should understand the value of truly decoupled layers. –  Jul 10 '13 at 17:53
  • How are your view models going to be view agnostic when they have event handlers for events defined in your view? –  Jul 10 '13 at 19:22

1 Answers1

3

Events implement a tight coupling between the publisher and subscribers, the format is rigid and difficult to scale. Most damningly, the publisher doesn't know who its subscribers are and thus will continue to publish even when all the subscribers have gone. This leads to memory leaks.

Moreover, if a ViewModel has handlers in it that listen for events originating on the user surface, those events must be artificially created somehow to run controlled tests on the ViewModel. And per your question, this can be hard to do.

Commands, on the other hand, are only executed when the ViewModel is in a predictable state and returns true to the CanExecute query. When the CanExecute query returns true, the command can be executed and its mutations can be observed precisely and comprehensively.

In practice, a ViewModel with lots of handlers in it gets tested when the developer fires up the app and looks for a given condition; a ViewModel that uses the command pattern can be tested at 2AM in the morning when everyone is home asleep.

Your example... User story: When I double click an item in the list box and then click 'ok' within 5 seconds, a query against the database should be generated. But only if it's Tuesday and only if it's raining in Bangkok.

Event Model: difficult to program, impossible to test comprehensively (unless it's Tuesday :) ), impossible to scale, after repeated bugs, user has low confidence in your work.

Command Model: simple to program, simple to test, 100% test coverage provable after each change to the requirements.

Gayot Fow
  • 8,710
  • 1
  • 35
  • 48