1

I have a form with several buttons: add, edit, delete etc. I can implement the add, edit and delete logic in add_click, edit_click, delete_click directly: update data in database directly in those functions. I can also use workItem.Commands[CommandNames.Add].Execute(); in add_click, and handle it in:

    [CommandHandler(CommandNames.Add)]
    public void OnAdd(object sender, object target)

What is the benifit to use the Microsoft.Practices.CompositeUI.Commands and CommandHandler? In which case I should use this? Is this the Microsoft implementation of general command pattern? Thanks!

MGwynne
  • 3,512
  • 1
  • 23
  • 35
spspli
  • 3,128
  • 11
  • 48
  • 75

1 Answers1

0

I think I can summarize some benefits here, they're all related to a better Separation of Concerns and appear clears especially in MVVM-like scenarios. Just to be clear you can do the sames things but I started to force myself using Command to force myself to write in a "clean" and "theoretically correct" way, to get used to it.

This said, separation of View and Code/Logic with Command approach is good because:

  • it's better for reuse: you can reuse UI object or the command logic without think to the other part; in case of a button, you basically avoid to write logic in the button itself, if you change from button to (example) a gesture you'll not touch the logic at all

  • it's better for maintenance: you focus on event arguments when write the event handler but when you switch to another control or another event you might have become very dependent on the event arguments, for example because the other control/event doesn't support the same arguments. Thus the code is just in a single place and can be shared easily (and the maintened), this brings developer to write better code. In case of shared dev teams (this is a "on field" tip) it's easy that every time a developer add some lines of code in a event handler, no problems about this if it works but if they have to edit a shared command block of code they have to do it in a more responsible way.

  • it's better for test automation: especially for shared blocks of code and for separation of testing teams; the UI team will write code to test the View and if it redesing the View he doesn't need to to link again to the events.

Some benefits are clear in medium-big projects and over time, but with the Command approach you become familiar with patterns and cleaner coding style, you get used to a more correct way to develop.

ADDITION: other interesting points about this argument are here

Community
  • 1
  • 1
vulcanik
  • 98
  • 1
  • 4