8
votes

Gestionnaires d'événements en xaml ou code derrière

Je suis nouveau à Silverlight et XAML. En essayant d'apprendre la syntaxe et les meilleures pratiques, je continue à contourner une divergence (ou du moins à moi, il semble que certaines manuelles d'événement implémentent.

dans un Exemple de MSDN Je vois le code suivant utilisé: P>

 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;
        }

c# xaml event-handling silverlight

1 commentaires

ni! Utilisez des commandes! ;) J'écrirais un échantillon approprié comme réponse, mais je suis un peu rouillé moi-même

4 Réponses :

4
votes

sauf si j'ai besoin de modifier de manière dynamique les gestionnaires d'événements pour un objet, je préfère la définir dans le XAML lui-même.

1 commentaires

Si je m'abonne à l'événement dans XAML, vous désinscrivez-vous automatiquement?

2
votes

Meilleure pratique: utilisez MVVM et substitut Commands pour les gestionnaires d'événements.

Autre que cela, il n'y a pas de "meilleure pratique" pour définir les gestionnaires d'événements de manière déclarée dans XAML ou via le code dans les constructeurs. C'est à vous.

Je penserais cependant que la plupart des gens s'attendent à voir les déclarations du XAML, en voyant comme c'est là que vous concevez l'interface utilisateur.

2 commentaires

Cela rend la très grande hypothèse que MVVM est toujours "la meilleure pratique". Je ne suis pas sûr que ce soit toujours vrai.

Regardez, si vous voulez mourir dans cette bataille, plus de pouvoir pour vous. Quant à moi, j'aimerais être d'abord à accueillir nos nouveaux Overlords MVVM. Sérieusement, Tho, j'aimerais voir le cas (autre que l'application la plus rudimentaire) où MVVM ne serait pas un meilleur choix.

5
votes

Dans la première approche, il existe deux "sites de code"

Le XAML où les éléments d'interface utilisateur sont définis et les événements sont câblés au même endroit.
Les procédures de gestionnaire d'événements dans le code derrière
dans le second il y a 3 "sites de code"
1. le xaml où les éléments de l'interface utilisateur sont définis
2. Le constructeur où les événements sont câblés
3. Les procédures de gestionnaire d'événements dans le code derrière
  Personnellement, je préfère la première approche. Si je supprime un élément, je n'ai besoin que de trouver les gestionnaires d'événements qui doivent être supprimés, je n'ai pas encore besoin de modifier également le constructeur de classe.
  Bien sûr, il s'agit de la règle de base, il y aura de nombreuses exceptions près.

0 commentaires

0
votes

Pour ce que vous valez, si vous essayez d'attribuer XAML à un modèle via une chaîne, les gestionnaires d'événements ne fonctionneront pas ... Voir Post:

événement Les gestionnaires lors de l'utilisation d'une chaîne en tant que modèle de données pour DataForm à Silverlight

0 commentaires