Comparaison entre l'infrastructure du Concepteur Windows Forms et l'infrastructure du Concepteur WPF

Article
08/10/2011

L'architecture du Concepteur WPF est considérablement différente de l'architecture du Concepteur Windows Forms, caractérisée par l'interface IComponent et l'espace de noms System.ComponentModel. Si vous avez créé des implémentations au moment du design personnalisées pour des contrôles Windows Forms, vous remarquerez que l'architecture du Concepteur WPF est plus aisée à utiliser et à étendre.

L'architecture du Concepteur WPF conserve les classes TypeConverter et TypeDescriptor du modèle objet du Concepteur Windows Forms. La plupart des autres aspects de l'architecture du Concepteur WPF sont différents. Pour plus d'informations sur l'architecture au moment du design Windows Forms, consultez Extension de la prise en charge au moment du design.

Différences principales entre l'infrastructure ComponentModel et l'infrastructure WPF

Les différences entre l'architecture du Concepteur WPF et l'infrastructure System.ComponentModel sont résumées dans le tableau suivant.

Infrastructure ComponentModel	Infrastructure du Concepteur WPF
Basée sur les interfaces IComponent, IContaineret ISite.	Basée sur la classe FrameworkElement.
S'appuie sur les services au moment du design fournis par un hôte.	Les concepteurs publient la configuration minimale requise de façon déclarative.
Type de concepteur dédié à chaque type de contrôle.	Il est possible d'utiliser un nombre quelconque de fonctionnalités sur un type de contrôle.
Les métadonnées sont codées en dur pour chaque type de contrôle ; fixées lors de la compilation du contrôle.	Les métadonnées sont déployées dans un assembly distinct ; peut être personnalisé ou remplacé par des outils. Cela permet la mise à jour des métadonnées au moment du design indépendamment du contrôle.
Un IDesignerHost conserve l'état du concepteur.	La classe EditingContext conserve l'état du concepteur.
Les services sont collectés et partagés avec une implémentation IServiceContainer.	La classe EditingContext détient les références de service.
Le BehaviorService gère clavier, souris et interactions de commande.	L'architecture des outils du Concepteur WPF gère les interactions avec le clavier, la souris et les commandes.
Le modèle objet d'édition se compose des contrôles à l'exécution, avec accès à liaison tardive via la classe PropertyDescriptor.	Le modèle objet d'édition fournit une couche d'indirection pour s'abstraire des contrôles à l'exécution. Les éditeurs de Catégories permettent l'édition de plusieurs propriétés dans une seule interface utilisateur.

IComponent etFrameworkElement

Les éléments WPF dérivent de la classe FrameworkElement, qui fournit la connexion entre les principaux services de WPF et les classes d'élément de niveau d'infrastructure.

Les éléments WPF n'implémentent pas l'interface IComponent. C'est l'une des raisons fondamentales pour laquelle le Concepteur WPF n'utilise pas l'infrastructure System.ComponentModel. Cela signifie que les contrôles WPF ne sont jamais installés. Par conséquent, les contrôles WPF ne peuvent pas demander de services concepteur de l'environnement de conception System.ComponentModel.

Services au moment du design

Les concepteurs de l'infrastructure System.ComponentModel demandent des services à l'environnement de conception. Dans l'infrastructure du Concepteur WPF, vous pouvez accomplir la plupart des tâches sans demander des services à l'environnement.

Dans l'infrastructure System.ComponentModel, il n'y aucune garantie que les services concepteur soient présents dans un hôte concepteur, ce qui signifie que le code concepteur personnalisé doit toujours vérifier une référence null après un appel de la méthode GetService. Le code concepteur doit pouvoir fonctionner en mode dégradé lorsqu'un service n'est pas présent et dans de nombreux cas cette contrainte ne peut être respectée.

Dans l'infrastructure du Concepteur WPF, un concepteur personnalisé publie la configuration minimale requise de façon déclarative. Si un hôte ne peut pas respecter le contrat, le concepteur ne se charge pas. Cela rend l'implémentation plus aisée et plus fiable.

Types concepteur dédiés et découplage des métadonnées

Dans l'infrastructure System.ComponentModel, un type concepteur est associé à son composant respectif par le bais de l'attribut de métadonnées DesignerAttribute. Cela signifie que la relation est établie lors de la compilation, en forçant une dépendance en dur entre les comportements au moment de l'exécution et au moment du design du composant. Pour joindre un concepteur différent, vous devez modifier la déclaration DesignerAttribute et recompiler la base de code du composant.

Dans le Concepteur WPF, les métadonnées de concepteur sont prises en charge dans un assembly distinct, les découplant physiquement de l'implémentation au moment de l'exécution. Cette liberté signifie que différents outils peuvent, pour le même type au moment de l'exécution, présenter des expériences utilisateur de conception complètement différentes. Pour plus d'informations, consultez AttributeTable.

Modèle objet d'édition

Dans l'infrastructure System.ComponentModel, les concepteurs personnalisés accèdent aux contrôles par liaison tardive via la classe PropertyDescriptor. Cette règle n'est pas imposée par l'environnement de conception et génère un bogue si un développeur oublie d'accéder à un contrôle via la classe PropertyDescriptor.

Dans l'infrastructure du Concepteur WPF, les concepteurs personnalisés interagissent avec les contrôles au moment de l'exécution via un modèle objet d'édition. Ce modèle fournit une couche d'indirection qui permet d'abstraire les contrôles dans un modèle et une vue. Ce modèle objet supprime le besoin d'accéder aux contrôles via la classe PropertyDescriptor.

Ressemblances avec l'infrastructure concepteur ComponentModel

Les contextes d'éditions forment la base du Concepteur WPF. La classe EditingContext contient l'état contextuel d'un concepteur.

Le contexte d'édition est conceptuellement semblable à l'interface IDesignerHost dans l'espace de noms System.ComponentModel.Design. L'interface IDesignerHost définit de nombreuses fonctionnalités, mais la classe EditingContext se concentre uniquement sur les données et le comportement.

Le contexte d'édition expose des services d'une façon semblable à l'interface IServiceContainer. Le contexte d'édition prend en charge l'énumération et ne prend pas en charge la suppression de services une fois qu'ils ont été ajoutés. Pour plus d'informations, consultez Architecture du contexte d'édition.

Différences dans l'utilisation des attributs

Les attributs concepteur ont des significations différentes dans les architectures du Concepteur WPF et de Windows Forms. Le tableau suivant décrit la différence d'utilisation d'un attribut concepteur entre les deux infrastructures.

Attribut	Fenêtre Propriétés Windows Forms	Fenêtre Propriétés de Concepteur WPF et Inspecteur de propriété Expression Blend
AmbientValueAttribute	Spécifie la valeur à passer à une propriété pour que celle-ci obtienne obtenir sa valeur d'une autre source. Ce concept est appelé ambiance.	N/A
BrowsableAttribute	Spécifie si une propriété ou un événement doit être affiché dans la fenêtre Propriétés.	Spécifie si une propriété ou un événement doivent être affichés dans une fenêtre Propriétés. En cas de définition explicite à true d'une propriété qui n'est normalement pas affichée, cette propriété sera affichée.
CategoryAttribute	Spécifie le nom de la catégorie dans laquelle grouper la propriété ou l'événement lorsqu'ils s'affichent dans un contrôle PropertyGrid défini en mode Par catégorie.	Spécifie le nom de la catégorie dans laquelle grouper la propriété en cas d'affichage dans une fenêtre Propriétés.
DefaultValueAttribute	Spécifie la valeur par défaut d'une propriété.	Pour les types de données CLR, spécifie la valeur par défaut pour une propriété. Ignoré pour les propriétés de dépendance.
DescriptionAttribute	Spécifie une description pour une propriété ou un événement.	N/A
DisplayNameAttribute	Spécifie le nom complet pour une propriété, un événement ou une méthode void publique qui ne prend pas d'arguments.	Spécifie le nom qui apparaîtra dans la fenêtre Propriétés pour la propriété à laquelle est appliqué cet attribut.
EditorAttribute	Spécifie l'éditeur à utiliser pour modifier une propriété.	Spécifie l'éditeur à utiliser pour modifier une propriété, y compris les éditeurs de catégorie de propriétés multiples.
EditorBrowsableAttribute	N/A	EditorBrowsableState.Advanced met un éditeur de catégories ou une propriété dans l'expanseur avancé.
HelpKeywordAttribute	Spécifie le mot clé de contexte pour une classe ou un membre.	N/A
LocalizableAttribute	Spécifie qu'une propriété doit être localisée.	N/A
PasswordPropertyTextAttribute	Indique que la représentation textuelle d'un objet est masquée par des caractères, tels que des astérisques.	N/A
ReadOnlyAttribute	Spécifie si la propriété à laquelle cet attribut est lié est en lecture seule ou en lecture/écriture au moment du design.	Spécifie si la propriété à laquelle cet attribut est lié est en lecture seule ou en lecture/écriture au moment du design. Les propriétés marquées par ReadOnlyAttribute afficheront l'objet en lecture seule dans l'éditeur de chaînes de l'Inspecteur de propriété.
RefreshPropertiesAttribute	Indique que la fenêtre Propriétés doit s'actualiser lorsque la valeur de propriété associée change.	N/A
TypeConverterAttribute	Spécifie quel type utiliser comme convertisseur pour l'objet auquel cet attribut est lié.	Spécifie quel type utiliser comme convertisseur pour l'objet auquel cet attribut est lié.
DefaultEventAttribute	Spécifie l'événement par défaut pour un composant.	Spécifie l'événement par défaut pour un composant, qui détermine le gestionnaire d'événements à créer lors d'un double-clic.
DefaultPropertyAttribute	Spécifie la propriété par défaut pour un composant.	Spécifie la propriété par défaut pour un composant, qui détermine la propriété sélectionnée par défaut.
DesignerAttribute	Spécifie la classe utilisée pour implémenter des services au moment du design pour un composant.	N/A
DesignerCategoryAttribute	Spécifie que le concepteur pour une classe appartient à une certaine catégorie.	N/A
ToolboxItemAttribute	Représente un attribut d'un élément de Boîte à outils.	N/A
ToolboxItemFilterAttribute	Spécifie la chaîne de filtrage et le type de filtre à utiliser pour une Boîte à outils.	N/A
ToolboxBrowsableAttribute	N/A	Utilisé pour empêcher un type de s'afficher dans la Boîte à outils lorsqu'un assembly est examiné pour choisir les types à ajouter à la Boîte à outils.
NewItemTypesAttribute	N/A	Utilisé pour spécifier quels éléments sont ajoutés à la zone de liste déroulante pour l'éditeur de collections ou l'éditeur de sous-propriétés. Autorise la spécification d'une fabrique pour personnaliser la création.
PropertyOrderAttribute	N/A	Utilisé pour spécifier l'ordre dans lequel les propriétés s'afficheront dans la fenêtre Propriétés.

Les attributs suivants sont utilisés dans l'infrastructure du Concepteur WPF mais pas dans l'infrastructure du Concepteur Windows Forms.

Différences de spécification des icônes de la Boîte à outils

Dans l'infrastructure du Concepteur Windows Forms, vous spécifiez une icône Boîte à outils pour votre contrôle personnalisé en appliquant ToolboxBitmapAttribute à votre classe de contrôle.

Dans l'infrastructure du Concepteur WPF, vous utilisez une ressource incorporée et une convention de nommage pour spécifier une image bitmap de Boîte à outils. De plus, vous utilisez le ToolboxBrowsableAttribute pour restreindre les types disponibles dans un assembly pour remplir une Boîte à outils.

Différences de spécification des métadonnées

Dans les Windows Forms, les métadonnées de concepteur sont spécifiées de façon déclarative, en appliquant des attributs tels que DesignerAttribute.

Dans l'architecture du Concepteur WPF, les métadonnées de concepteur sont spécifiées dans une AttributeTable.

Voir aussi

Autres ressources

Extensibilité du Concepteur WPF

Extension de la prise en charge au moment du design