Conseil n° 6 : Simplifiez vos liaisons et votre code de validation

Par exemple, si vous écrivez une fenêtre Person Editor qui possède une propriété EmailAddress, il faudra un moyen de valider l’adresse de messagerie et d’informer l’utilisateur si elle n’est pas valide. Vous aurez peut-être aussi le cas où les administrateurs peuvent afficher tous les détails d’une personne, tandis que les non-administrateurs peuvent tout visualiser, à l’exception du salaire de la personne. Dans ce cas, votre VueModèle devra vérifier le type d’utilisateur et définir la visibilité du champ Salary. 

Autrement dit, pour quasiment chaque champ de votre page, votre VueModèle aura les éléments suivants :

1. Une propriété pour la valeur à afficher/modifier.
2. Une propriété Boolean indiquant si ces valeurs sont valides.
3. Une propriété string contenant le message d’erreur en cas d’invalidité de la valeur.
4. Une propriété Boolean indiquant si le champ doit ou non être visible.

Par conséquent, ce qui au départ se limitait à un petit nombre de champs dans votre VueModèle relativement simple a été multiplié par un facteur quatre en raison des métadonnées associées au champ. 

Vous pouvez tailler dans cet encombrement de métadonnées en créant un objet générique chargé de représenter le champ, par exemple ViewModelField<T>. La version éclatée de PersonViewModel a besoin de quatre propriétés distinctes, Salary, IsSalaryVisible, IsSalaryValid et SalaryValidationMessage, pour représenter Salary. A l’inverse, la version qui utilise ViewModelField<int> en a besoin d’une seule. Lorsque vous pensez à ce que cela signifie pour l’intégralité de PersonViewModel, une approche aboutit à 14 propriétés (majoritairement similaires) et l’autre n’en comporte que cinq.

Lorsque vous implémentez vos Vues, beaucoup de propriétés de VueModèle signifie l’écriture, la maintenance et le débogage de nombreuses liaisons des données Data Context. La création d’un modèle de conception commun pour votre logique de VueModèle commune constitue un début dans la simplification de vos liaisons de données en créant des contrôles personnalisés qui savent comment dialoguer efficacement avec vos propriétés ViewModelField<T>. Voici le code XAML nécessaire pour afficher et lier le champ Salary sans ViewModelField<T> :

<Grid Visibility= »{BindingIsSalaryVisible …}} »>
<Grid.RowDefinitions>
<RowDefinition />
</Grid.RowDefinitions>
<StackPanel Orientation= »Vertical »>
<TextBlock Text= »SALARY » />
<TextBlock Text= »{BindingSalaryValidationMessage} »
 Visibility= »{BindingIsValid …}} » Foreground= »Red » />
<TextBox Text= »{Binding Salary, Mode=TwoWay} » />
</StackPanel>
</Grid>

Ce code est plutôt complexe pour un champ et cette technique commence à manquer sérieusement d’élégance lorsque vous liez l’intégralité de PersonViewModel, et c’est toujours le même refrain. Grâce à ViewModelField<T> et à un contrôle textbox personnalisé, vous pouvez non seulement encapsuler et réutiliser l’agencement, de sorte que votre Vue a un aspect homogène, mais vous pouvez aussi simplifier le code XAML dans la page qui contient le contrôle. Par ailleurs, il n’y a qu’une seule liaison, comme illustré sur le listing 4.

Listing 4 :

<StackPanel>
<controls:TextboxField
DataContext=”{Binding Id}”
LabelText=”Salary”/>
<controls:TextboxField
DataContext=”{BindingFirstName}”
LabelText=”First Name”/>
<controls:TextboxField
DataContext=”{BindingLastName}”
LabelText=”Last Name”/>
<controls:TextboxField
DataContext=”{BindingEmailAddress}”
LabelText=”Email Address”/>
<controls:TextboxField
DataContext=”{Binding Salary}”
LabelText=”Salary”/>
</StackPanel>

Le recours à ViewModelField<T> et aux contrôles personnalisés peut simplifier considérablement le code pour vos VueModèles et Vues, et éliminer ainsi une grande partie du code dupliqué ou quasiment identique de votre application. D’autre part, une fois que vous avez créé et testé vos contrôles personnalisés, l’écriture du reste de l’application commence à être nettement plus rapide car vous pouvez ajouter de nouveaux champs et VueModèles sans écrire beaucoup de code.

Le modèle MVVM constitue un outil indispensable afin de développer des applications pour Silverlight, Windows Phone 7 et WPF. Si vous évitez certains des chausse-trappes architecturaux et associez MVVM à d’autres modèles de conception comme Repository et Adapter, il est facile d’écrire des applications adaptées aux tests unitaires et aux opérations de maintenance.