views:

306

answers:

3

I am new to Silverlight and XAML. While trying to learn the syntax and best practices I continue to come across a discrepancy (or at least to me it seems that way) in the way some implement event handlers.

In an example from MSDN I see the following code used:

<UserControl x:Class="DragAndDropSimple.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    Width="400" Height="300">
  <Canvas x:Name="rootCanvas"
  Width="640"
  Height="480"
  Background="Gray"
  >
    <!-- You can drag this rectangle around the canvas. -->
    <Rectangle
    MouseLeftButtonDown="Handle_MouseDown"
    MouseMove="Handle_MouseMove"
    MouseLeftButtonUp="Handle_MouseUp"
    Canvas.Left="30" Canvas.Top="30" Fill="Red"
    Width="50" Height="50" />
  </Canvas>

</UserControl>

Where the mouse handlers are set, however, in other code I have seen this method used in the code behind:

 public Window1()
        {
            InitializeComponent();

            TransformGroup group = new TransformGroup();

            ScaleTransform xform = new ScaleTransform();
            group.Children.Add(xform);

            TranslateTransform tt = new TranslateTransform();
            group.Children.Add(tt);

            image.RenderTransform = group;

            image.MouseWheel += image_MouseWheel;
            image.MouseLeftButtonDown += image_MouseLeftButtonDown;
            image.MouseLeftButtonUp += image_MouseLeftButtonUp;
            image.MouseMove += image_MouseMove;
        }

I would assume the example on MSDN is the recommended way, however, I tend to like the second method.

Is there a best practice for this situation?

+2  A: 

Unless I need to dynamically modify the event handlers for an object, I prefer to define it in the XAML itself.

Parrots
A: 

Best practice: Use MVVM and substitute ICommands for event handlers.

Other than that, there is no "best practice" for setting event handlers declaratively in xaml or via code in constructors. Its up to you.

I'd think, however, that most people would expect to see the declarations in the xaml, seeing as that's where you're designing the UI.

Will
This makes the quite large assumption that MVVM is always "best practice". I'm not sure that is always true.
AnthonyWJones
Look, if you want to die in that battle, more power to you. As for me, I would like to be first to welcome our new MVVM overlords. Seriously, tho, I'd like to see the case (other than the most rudimentary application) where MVVM would not be a best choice.
Will
+2  A: 

In the first approach there are two "code sites"

  1. the XAML where the UI elements are defined and the events are wired up in the same place.
  2. The event handler procedures in code behind

In the second there are 3 "code sites"

  1. the XAML where the UI elements are defined
  2. the constructor where the events are wired up
  3. The event handler procedures in code behind

Personally I prefer the first approach. If I delete an element I need only find the event handlers that need removing, I don't then need to edit the class constructor as well.

Of course this is rule of thumb there will be many exceptions.

AnthonyWJones