Functor Pattern: Separating Layout from Behaviour in SilverLight Control Design

SilverLight controls may get complicated when it has to handle mouse events and keyboard events. When too many events need to be handled the size of the code behind may grow to a big size. In this post, I'll show a design structure that separates the event handling logic from the layout of the Control. The purpose is to avoid code behind file growing into unmanagable size.

This simple example assumes you need a control to handle the following requirements:
1. There is a part in the control where user's left click must turn the control into "selected" mode
2. There is a part in the control where user's left click must invoke a sorting operation according to the sorting parameter bound to the control
3. When user right click on any part of the control, a context menu should be shown

The "normal" way of handling mouse events is to either override the mouse event functions in the UserControl class, or add mouse handler functions in the control. Putting user gesture event handling code in the code behind file is the main force that drives its size to grow. To avoid this problem, we'll use a set of mouse handler classes to handle these events instead.



Here is the layout of the control.



Other classes.



Here is the start up wiring.



Here is how we handle the first requirement.


Now sorting.


This is how context menu is created.


As shown above, the main control doesn't have any mouse event handling logic but some supporting functions. There is no if-else logic to resolve where the mouse left click is and what it means, sorting or selecting. There is no reason for the size of the code behind file to grow out of control when more complicated mouse handling is required. Each mouse handler class does one thing and one thing only.

Further more, the main control class has a much better chance to be reused since different usages may choose what mouse handlers to attach or not attach to give it different behaviour, e.g. not allow sorting. People may also override MouseHandler functions in derived MouseHandlers to provide different behaviour while no change is needed to the main control class. By attaching and detaching MouseHandlers at runtime, the main controls behaviour can also be changed at runtime.

The same approach can be applied to keyboard handling as well.

In C# implementation you don't really need the MouseHost class. Just add and extension to the UserControl class.

public static class MouseExtension
{
public static AttachMouseHandler(this UserControl userControl, IMouseHandler mouseHandler)
{
userControl.MouseEnter += mouseHandler.OnMouseEnter;
...
}
public static DetachMouseHandler(this UserControl userControl, IMouseHandler mouseHandler)
{
userControl.MouseEnter -= mouseHandler.OnMouseEnter;
...
}

}