Code-behind et XAML dans WPF

Article
08/10/2011

Code-behind est un terme utilisé pour décrire le code joint avec les objets définis par balisage, lorsqu'une page XAML est compilée par balisage. Cette rubrique explique les exigences liées au code-behind et décrit un mécanisme alternatif de code incorporé pour le code en XAML.

Cette rubrique contient les sections suivantes :

Composants requis
Code-behind et langage XAML
Exigences concernant le code-behind, le gestionnaire d'événements et les classes partielles dans WPF
x:Code
Limitations liées au code incorporé

Composants requis

Cette rubrique part du principe que vous avez lu Vue d'ensemble du langage XAML (WPF) et possédez des connaissances de base de CLR et de la programmation orientée objet.

Code-behind et langage XAML

Le langage XAML inclut des fonctionnalités de niveau de langage qui permettent d'associer des fichiers de code aux fichiers de balisage, du côté du fichier de balisage. Spécifiquement, le langage XAML définit les fonctionnalités de langage x:Class, directive, x:Subclass, directive et x:ClassModifier, directive. En revanche, le langage XAML ne spécifie pas comment le code doit être produit et comment intégrer le balisage et le code. C'est aux infrastructures telles que WPF que revient de déterminer comment intégrer le code, comment utiliser XAML dans l'application et les modèles de programmation, et les actions de génération ou les autres supports requis.

Exigences concernant le code-behind, le gestionnaire d'événements et les classes partielles dans WPF

La classe partielle doit dériver du type de la classe qui stocke l'élément racine.
Notez que, du côté du code-behind, avec le comportement par défaut des actions de génération de compilation du balisage, vous pouvez laisser l'espace de dérivation dans la définition de classe partielle. Le résultat compilé supposera que le type de stockage de la racine de page sera la base de la classe partielle, même s'il n'est pas spécifié. Toutefois, compter sur ce comportement n'est pas une meilleure pratique.
Les gestionnaires d'événements que vous écrivez dans le code-behind doivent être des méthodes d'instance et ne peuvent pas être des méthodes statiques. Ces méthodes doivent être définies par la classe partielle dans l'espace de noms CLR identifié par x:Class. Vous ne pouvez pas qualifier le nom d'un gestionnaire d'événements pour demander à un processeur XAML de rechercher un gestionnaire d'événements en vue de la transmission des événements dans une portée de classe différente.
Le gestionnaire doit correspondre au délégué pour l'événement approprié dans le système de types de stockage.
De manière spécifique, pour le langage Microsoft Visual Basic, vous pouvez utiliser le mot clé Handles spécifique au langage pour associer des gestionnaires à des instances et des événements dans la déclaration de gestionnaire, au lieu de joindre des gestionnaires avec des attributs en XAML. Cette technique présente toutefois certaines limitations car le mot clé Handles ne peut pas prendre en charge toutes les fonctionnalités spécifiques du système d'événements WPF, tel que certains scénarios d'événements routés ou événements attachés. Pour plus d'informations, consultez Gestion des événements Visual Basic et WPF.

x:Code

x:Code est un élément directeur défini dans XAML. Un élément de directive x:Code peut contenir un code de programmation incorporé. Le code défini en ligne peut interagir avec le XAML sur la même page. L'exemple suivant illustre le code C# incorporé. Notez que le code est à l'intérieur de l'élément x:Code et qu'il doit être entouré par <CDATA[...]]> pour se soustraire au contenu de XML, de manière à ce qu'un processeur XAML (interprétant le schéma XAML ou WPF ) n'essaie pas d'interpréter le contenu littéralement en tant que code XML.

<Page
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="MyNamespace.MyCanvasCodeInline"
>
  <Button Name="button1" Click="Clicked">Click Me!</Button>
  <x:Code><![CDATA[
    void Clicked(object sender, RoutedEventArgs e)
    {
        button1.Content = "Hello World";
    }
  ]]></x:Code>
</Page>

Limitations liées au code incorporé

Évitez ou limitez l'utilisation de code inline. En termes d'architecture et de philosophie du codage, la séparation entre balise et code-behind permet d'attribuer des rôles bien distincts au concepteur et au développeur. À un niveau plus technique, le code que vous écrivez pour le code inline peut être plus difficile à écrire, parce que vous écrivez toujours dans la classe partielle XAML générée et que vous pouvez uniquement utiliser les mappages d'espaces de noms XML par défaut. Comme vous ne pouvez pas ajouter d'instructions using, vous devez qualifier entièrement la plupart des appels API que vous faites. Les mappages WPF par défaut incluent la plupart mais pas tous les espaces de noms CLR qui sont présents dans les assemblys WPF ; vous devrez qualifier pleinement des appels aux types et aux membres contenus dans les autres espaces de noms CLR. Vous ne pouvez rien définir non plus au-delà de la classe partielle dans le code inline, et toutes les entités de code utilisateur que vous référencez doivent exister en tant que membre ou variable dans la classe partielle générée. Enfin, d'autres fonctionnalités de programmation spécifiques au langage, telles que les macros ou #ifdef pour les variables globales ou les variables de génération, ne sont pas disponibles. Pour plus d'informations, consultez x:Code, type XAML intrinsèque.