6 conseils sur l’approche Modèle-Vue-VueModèle

L’approche Modèle-Vue-VueModèle ou MVVM de Microsoft constitue un outil indispensable en vue de développer des applications pour Silverlight, Windows Phone 7 et Windows Presentation Foundation. Cet article va vous aider à éviter les pièges architecturaux et à créer des applications adaptées aux tests unitaires et aux opérations de maintenance.

6 conseils sur l’approche Modèle-Vue-VueModèle

Après avoir travaillé sur un projet Silverlight 4 pendant les 18 derniers mois, j’ai appris un certain nombre de choses sur la loyauté des couches, l’organisation du code, les tests unitaires et le code maintenable. Bien évidemment, cela m’a permis de me forger une opinion sur l’implémentation de l’approche MVVM (Model-View-ViewModel) et j’ai pu utiliser les modèles Repository et Adapter afin d’obtenir de meilleurs résultats. Cela semble compliqué, mais il n’y a pas de raison qu’il en soit ainsi, en particulier avec ses six conseils utiles pour éviter les pièges architecturaux et obtenir les résultats souhaités : séparation des différents aspects, testabilité et maintenance facilitée à mesure que votre application évolue.

Pour commencer, que recouvre l’acronyme MVVM ?

Il s’agit d’une approche d’organisation du code et de testabilité employée couramment dans les applications Silverlight, Windows Phone 7 et Windows Presentation Foundation (WPF), afin de vous aider à combler le fossé entre votre code d’interface utilisateur et votre couche « métier » ou le code de Modèle de domaine (Domain Model). Les Vues (View) sont vos fichiers *.xaml, les Modèles (Model) sont vos objets de modèle de domaine et les VueModèles (ViewModel) sont les représentations logiques de vos vues sans les éléments spécifiques à l’interface utilisateur.

Vos classes ViewModel n’ont pas de types spécifiques à l’interface utilisateur tels que TextBox ou Label, mais font appel à des types tels que string, int et DateTime.

Si vous avez une Vue nommée PersonDetail.xaml qui permet à l’utilisateur d’afficher et de modifier des informations sur une personne, vous allez avoir une classe ViewModel intitulée PersonViewModel. Si vous avez un contrôle TextBox sur votre Vue qui affiche le prénom de la personne, vous allez avoir une propriété sur la VueModèle intitulée FirstName et représentant une chaîne. Si votre Vue comporte un bouton Save, votre VueModèle comportera une propriété du type ICommand et intitulée SaveCommand. Les Vues et les VueModèles sont interconnectées via des expressions de liaison de données sur les contrôles d’interface utilisateur.

A l’instar de son modèle frère, Modèle-Vue-Contrôleur (MVC), MVVM vous aide pour les tests unitaires de votre application. Pour ce faire, il réduit au minimum la quantité de code disponible dans vos fichiers code-behind (*.xaml.cs, *.xaml.vb). Pourquoi cette approche est-elle si cruciale pour les tests unitaires ? Un des problèmes clés des tests unitaires concerne la manière de tester une instance en cours d’exécution de l’interface utilisateur. Cela relève du défi car les infrastructures de tests unitaires telles que NUnit et MSTest sont axées sur les tests de classes ordinaires. Il va de soit qu’une page XAML est une classe, mais elle est accompagnée de beaucoup d’autres éléments qui sont liés à Windows et sont notoirement difficiles d’automatiser.

Vous allez peut-être penser à la chose suivante : Microsoft Test Manager (MTM) et les tests Coded UI dans Visual Studio 2010 ne résolvent-ils pas ce problème ? En fait, oui et non. Ces outils facilitent considérablement l’automatisation des tests de l’interface utilisateur d’une application en cours d’exécution, mais il s’agit d’un type de test différent. MTM et les tests Coded UI ciblent généralement les tests d’intégration d’une application déployée. Il existe une distinction d’approche entre les tests d’intégration et les tests unitaires. Les premiers testent les fonctionnalités complètes d’une application déployée, tandis que les seconds testent des parties de fonctionnalités de manière isolée. En quelque sorte, les tests d’intégration sont des « macro-tests » et les tests unitaires, des « micro-tests ». D’une certaine manière, l’utilisation de MVVM et des tests unitaires résout le problème des tests d’interface utilisateur en ne testant pas celle-ci. Les VueModèles sont une abstraction représentant l’état et la logique sous-jacents à l’interface utilisateur, de sorte que vous pouvez réduire au minimum la quantité d’éléments difficiles à tester, pour vous focaliser sur les éléments faciles sur ce plan, à savoir les classes ViewModel non-Windows que vous écrivez en C# ou Visual Basic .NET.