From JohnPapa.net, “Siliverlight 2-Tip – Declaring Events.”

He thinks that the place to wire up an event is always in code rather than in markup (like XAML).

“What’s my opinion? I firmly believe the handlers belong in the code and not in the XAML.”

I’d suggest that’s not always right either (and maybe not the right question to ask). This technique doesn’t allow the designer to have freedom to decide how to build the interface freely. If you wire up to a “button” click, then the designer has to implement a certain UI feature as a button. Maybe that’s not what they wanted. The UI/code are wound together extremely tightly when using this pattern.

A command/message driven architecture that splits the actual implementation as much as possible is the best pattern for growth and true separation of roles. That being said, it’s not always practical to build a system like that.

I like the CONCEPT of WPF’s RoutedCommand system which is a way in WPF to handle this pattern, but I don’t care for the way that things are enabled and disabled via the CanExecute event handlers. The event handlers can be called hundreds of times a minute depending on your user interface.

The bad news is that Silverlight doesn’t lend itself easily to a message/command driven architecture (as the RoutedCommand system isn’t available in Silverlight 2.0). So what’s a developer to do? :)

I like the ‘toolability’ of doing inline (in XAML) wire-up of events. If the developer just provides a common set of end-points (events) to the UI designer, then they may have an opportunity to more freely control and adjust the user interface as needed without requiring code changes.

So in John’s example code, instead of

btnAddToCard.Click += new RoutedEventHandler(btnAddToCard_Click);

It might be better to provide a method called:

AddToCard(object sender, RoutedEventArgs e) {

}

That way, the designer can wire-up any way they want.

Or, I suppose one could build a rudimentary message/command system by using attached properties and a common event handler which handles all command driven user interface elements. (And now that I think about that more — I think that could end up being quite slick if done carefully).