Event vs Command...

Topics: CAB & Smart Client Software Factory
Sep 13, 2007 at 5:00 PM

I'm learning CAB and I've read a lot of document about its capabilities...
I'm a little confused about Commands and Events, above all from a logical point of view...

These two concepts seems to be overlapped, and in certain situations I can't figure if it's better to use commands or events...Can anyone give me some headlines for understanding in which situation is recommended to use Command, and when instead is better to use the EventBroker system??

Sep 13, 2007 at 9:25 PM
For what it is worth...

I use a command handler if what I want to do also is associated with a button click or menu selection.

An event happens incidental to an action; it is not the point of the action.

For instance:

I have a person form that retrieves person info when I click the get button. GetPerson() is a command. I can invoke it from the menu or a click handler.

I have a tree of IDs. If I double click a person node in the tree, the tree raises the event "PersonSelected". The event handler for 'PersonSelected' is subscribed to by my person form. The event handler invokes the command GetPerson.

The tree does not 'know' what is going to happen when the event is raised, although the tree 'knows' exactly why it is raising the event.. The person form 'knows' exactly what will happen when the GetPerson() command is invoked but it has not idea why it was invoked.

If the tree invoked the GetPerson command, it would need to know about the 'benefactor' of the command. This is fine for buttons and menus but not for a loosely connected, reusable form. If I used the command invocation, when I moved the tree to another application, I would have to keep the GetPerson functionality and include an info form. That ties the two SmartParts too close together. Using the Event, I don't have to do anything. I could fire events off all day long with no handlers and no one would care (The previous statement may be an oversimplification - confirm it or experiment).

Hope it helps

Sep 14, 2007 at 4:33 AM
This is what we do where I work:

We only use CommandHandlers for ToolStrip and MenuStrip items. That's it. Everything else we do with an EventBroker event (which have more power due to their ability to pass complex event arguments).

When it comes to buttons on forms, we delegate any and all actions to the Presenter, which then fires an EventBroker event if necessary.

I've found this style of eventing to be the easiest to use. It makes things simple so everyone on the development team knows exactly what to do in a given situation. It also makes all communication between the presenter and view explicit, clear and easy to test.

You can do it other ways. We do it this way for the sake of clarity and testability.
Sep 14, 2007 at 10:20 AM
thanks a lot for your suggestions,

@mklapp: I've understand your explication/argumentation but I'm still in doubt about a fact..pone that I have 2 buttons (A e B, for example) that raised the same event, so, when I click on each of them, the same EventHandler is called, rigth? My question is...in the EventHandler body HOW can I know which button bewteen A e B has been clicked? Please, can you post me some code (just the one to make me undestading this fact) ?

@Chris: I know there are different ways to accomplish this task...but I want to find the one that permit to mantain a loosing-coupled high level, clarity and testability, as you said...In your opinion, referring to the example (A e B button) above, what is the "best" way to obtain (in EventHandler's body) the id ("a" o "b") of the button that has been clicked?

Waiting your reply, thanks
Sep 14, 2007 at 2:09 PM
Keeping in mind there is more than one way to do this....

Each button has its own click handler that can be set through control's property box or in code or wherever. From within that handler (unique to each button), the EventBroker Event can be raised with an appropriate argument .

For Instance:

//Define the Event

EventPublication("topic://SESRegistration/StudentAdded", PublicationScope.WorkItem)
public event EventHandler<DataEventArgs<string>> PersonSelected;

//Handle Click by raising the event
cmd1_click(object sender, EventArgs e)
PersonSelected(this, new DataEventArgs<string>("Button1")); //Note button 'name'
cmd2_click(object sender, EventArgs e)
PersonSelected(this, new DataEventArgs<string>("Button2")); //Note button 'name'

//Implement the event

EventSubscription("topic://SES/StudentFound", Thread = ThreadOption.UserInterface)
public void StudentFound(Object sender, DataEventArgs<string> buttonID)
if(buttonID.Data.ToString() == "Button1")