Conseil n° 1 : Séparez impérativement le Modèle de la VueModèle.

Prenons le cas d’un écran qui modifie les informations d’une personne : ID, FirstName, LastName, EmailAddress. Si vous n’avez pas énormément de logique métier ou de logique de validation complexe, le fait d’avoir une classe PersonViewModel et une classe de modèle Person donnera une impression d’excès ou de duplication du code. Ces deux classes seront effectivement fortement similaires. L’un des aspects formidables de Silverlight/WPF et MVVM est la possibilité d’employer la liaison de données ou data binding. Il est inutile d’écrire des tonnes d’instructions d’affectation pour obtenir les données de votre VueModèle sur votre Vue, et le code-behind pour votre Vue reste extrêmement propre. Avec la liaison de données bidirectionnelle, votre VueModèle est rafraîchie à partir de votre Vue dès que l’utilisateur clique en dehors d’un champ.

Séparez impérativement le Modèle de la VueModèle

J’ai compris l’importance de la séparation stricte entre le Modèle et la VueModèle lorsqu’il m’a fallu implémenter un bouton Cancel. Supposons que vous modifiiez un enregistrement Person existant et que vous utilisiez la liaison de données bidirectionnelle. Vous modifiez le prénom, le nom, l’adresse électronique, puis vous réalisez que vous vous êtes complètement trompé et vous souhaitez annuler vos modifications. A ce stade, la VueModèle est déjà mise à jour du fait de la liaison de données bidirectionnelle et les mêmes valeurs sont affichées sur la Vue.

Si vous avez « joué la carte de l’économie » et combiné le Modèle et la VueModèle, vous ne pouvez rien annuler et il faut recharger l’enregistrement Person à partir de la base de données. En revanche, si vous avez un Modèle et une VueModèle séparés, il vous suffit de ne pas migrer les changements vers le Modèle. Au lieu de cela, vous rafraîchissez votre VueModèle à partir du Modèle et votre fonctionnalité d’annulation est complète.

Cela illustre un point clé de la loyauté des couches. Les Vues et VueModèles consistent à afficher les éléments à l’utilisateur dans une implémentation d’interface utilisateur spécifique. Le Modèle ne se préoccupe pas du mode d’affichage des données, mais plus des règles métier et de la logique de persistance.

Les Vues et VueModèles servent à afficher et collecter les données auprès de l’utilisateur, mais lorsque l’enregistrement effectif se produit, les données de la VueModèle sont copiées vers le Modèle et c’est ce dernier qui est enregistré.

Dans l’exemple tout simple d’un éditeur Person, il existe un mappage 1 à 1 entre la Vue, la VueModèle et le Modèle. Lorsque vos Vues deviennent plus complexes, ce mappage change. Il existe presque toujours un mappage 1 à 1 entre la Vue et la VueModèle, mais lorsque les Vues (et donc les VueModèles) deviennent complexes, la VueModèle devra peut-être dialoguer avec deux Modèles ou plus afin de remplir les données et de les enregistrer sur cette Vue. C’est le second cas où des « économies de bout de chandelle » concernant la séparation entre la Vue, la VueModèle et le Modèle peuvent vous attirer des ennuis.