Architecture du modèle d'édition

Article
08/10/2011

L'implémentation au moment du design interagit avec les contrôles au moment de l'exécution via une interface de programmation appelée modèle d'édition. Les objets conçus sont appelés objets modifiables. Cette rubrique décrit l'architecture et l'utilisation du modèle d'édition dans le Concepteur WPF pour Visual Studio.

Vos contrôles sont définis en langage XAML (Extensible Application Markup Language). Vous mettez à jour le code XAML de vos contrôles par programmation à l'aide du modèle d'édition.

Modèle, wrapper et vue

Le modèle d'édition se compose de trois sous-unités fonctionnelles : un modèle, un wrapper public, qui permet d'abstraire le modèle, et une vue, qui représente l'interface utilisateur du modèle. Le modèle et la vue sont distincts, mais le wrapper et le modèle sont étroitement liés. L'illustration suivante montre la relation entre les trois sous-unités.

Relations entre Model, ModelItem et View

L'environnement de conception utilise le type ModelItem pour communiquer avec le modèle sous-jacent. Toutes les modifications sont apportées aux wrappers ModelItem, qui affectent le modèle sous-jacent. Cela permet au modèle d'être simple. Les wrappers ModelItem gèrent des fonctionnalités de concepteur complexes, comme la prise en charge des transactions, le suivi des annulations et les notifications de modification.

Création d'une instance

Toutes les fonctionnalités du concepteur qui nécessitent la création d'objets sur l'aire de conception utilisent la classe ModelFactory. Chaque objet du concepteur est encapsulé avec une instance de ModelItem. Les éléments de modèle sont créés par ModelFactory.

Le code suivant montre un appel courant de ModelFactory

ModelItem newButton = ModelFactory.CreateItem(_context, typeof(Button));

La méthode CreateItem retourne toujours un type de données ModelItem. Il s'agit du type de base pour tous les éléments dans le modèle d'édition du Concepteur WPF ; il représente une instance encapsulée du type passé à la méthode CreateItem. La méthode CreateItem requiert également une instance d'un contexte d'édition du Concepteur WPF (_context dans l'exemple de code précédent), qui sert à localiser les autres services et les dépendances dans le concepteur.

La création d'éléments explicites dans la fabrique ne s'avère importante que pour les objets à placer sur l'aire de conception qui peuvent comporter initialiseurs par défaut. Cette procédure n'est pas nécessaire si vous affectez simplement des valeurs aux propriétés.

Utilisez toujours la méthode CreateItem pour créer des objets sur l'aire de conception. Car de nombreuses instances brutes ne peuvent pas être analysées dans des éléments de modèle. Une fois une valeur définie dans le modèle, interagissez uniquement via le modèle. L'instance qui stocke le modèle peut être reconstruite par le Framework à tout moment, ce qui invalide toutes les références mises en cache.

Options de création

Vous devrez parfois personnaliser le comportement de création de vos objets. Par exemple, un composant de connexion à la base de données peut ne pas interroger la base de données au moment du design. La première fois que vous créez un composant, vous pouvez disposer du contrôle sur la création d'une instance.

Dans ce cas, un composant est déplacé de la boîte à outils ou collé du Presse-papiers. Vous pouvez préconfigurer le composant à l'aide de valeurs par défaut utilisables. Si elles ne sont pas modifiées, ces valeurs par défaut sont sérialisées en code XAML.

Vous pouvez passer un jeu facultatif d'indicateurs à la méthode CreateItem à l'aide de l'énumération CreateOptions.

L'indicateur InitializeDefaults est utilisé par des outils tels que l'outil de création pour initialiser un jeu de valeurs de propriété préconfigurées. Par exemple, ContentControl peut fournir du contenu par défaut. Cette opération ne remplace toutefois pas la spécification correcte de valeurs de propriétés par défaut dans le code du contrôle runtime.

Les valeurs définies avec cet indicateur sont conservées dans le code XAML.

Cet indicateur ne doit pas être utilisé lors de l'analyse du code, car les valeurs par défaut peuvent avoir été supprimées par l'utilisateur lors de la modification de l'objet dans le concepteur.

La méthode CreateItem route l'appel de CreateItem. Cette méthode exécute plusieurs étapes, présentées dans l'organigramme suivant.

Création d'instance explicite utilisant l'APi de création

Remplacement du parent d'un élément par un nouveau conteneur

Outre la création d'éléments, une autre tâche courante du concepteur est de remplacer le parent d'un élément par un autre. Cette tâche est gérée via une classe statique nommée ModelParent, qui fournit des fonctionnalités communes à la plupart des spécifications de parentage.

Localiser un objet parent valide, en fonction d'un décalage de coordonnée ou élément de début dans la hiérarchie à rechercher.
Déterminer si un objet donné peut être un parent d'un type particulier.
Remplacer le parent d'un objet par un autre. Cette modification supprime également l'ancien parent de l'objet. Cette suppression permet à l'ancien parent de nettoyer des données, par exemple, des propriétés attachées, qui peuvent résider sur l'élément.

La classe ModelParent localise une classe ParentAdapter pour les objets parents actuels et proposés. Si aucune classe ParentAdapter n'existe, un objet ne peut pas être assigné à un parent. La classe ParentAdapter définit plusieurs substitutions pour des cas courants. Par exemple, de nombreuses substitutions acceptent un objet GestureData comme paramètre. Ce type de données est disponible à partir du mécanisme de commande du Concepteur WPF lorsque le code gère une commande utilisateur. Il fournit des informations contextuelles communes.

ParentAdapter permet aux conteneurs d'exécuter une suppression intelligente du parent. Par exemple, si un objet associé à un parent de contrôle Canvas est remplacé par un parent de contrôle Grid, les propriétés attachées du contrôle Canvas sur l'objet peuvent être automatiquement supprimées.