Dans le vif du sujet

la véritable couche d’interface utilisateur, qui constitue la vue. Cette approche MVVM supprime la logique de la vue en s’appuyant sur la liaison des données et sur un modèle de commande. La vue correspond au contrôle utilisateur, le modèle représente les données métier et les services logiques, et le modèle Vue constitue la passerelle entre tous ces éléments. Un des avantages de l’approche MVVM est qu’elle simplifie la vue et sépare toute votre logique, de sorte que vous pouvez la trouver et, potentiellement, la réutiliser avec différentes technologies.

La réutilisation constitue souvent un objectif insaisissable, mais même si celle-ci est impossible directement, le fait de s’appuyer sur la liaison de données et le modèle de commande permet de savoir beaucoup plus facilement ce que réalise votre application. Une des distinctions entre la logique dans le modèle Vue et la logique dans le modèle est le fait que le code du modèle est réutilisable au sein de l’application Silverlight, mais aussi à partir d’ASP.NET, de WinForms, du workflow et des services.

Le modèle Vue possède une relation univoque directe avec une vue spécifique : il constitue littéralement le port entre une vue spécifique et le modèle. Les vues ont une structure identique, peu importe qu’elles fournissent des données opérationnelles, telles que les noms d’utilisateur et mots de passe de connexion, ou des données persistantes, par exemple les détails des clients. Le contexte de données de liaison de la vue est le modèle Vue, tel que Login ViewModel. Si vous utilisez massivement les styles et si vous appliquez des styles implicites dans le code ou via le prochain gestionnaire de styles implicites, votre vue peut être très simple :

L’aspect commande permet de voir de manière particulièrement claire quelles fonctions l’utilisateur est censé effectuer lorsqu’il se sert de l’application. Cela présente certains défis car Silverlight ne propose pas de modèle de commande. Pour rester simple, le modèle Vue de l’exemple contient une propriété CanLogin. Je lie la propriété IsEnabled du bouton de connexion à cette propriété. Cela fonctionne car le modèle Vue implémente INotify PropertyChanged et les propriétés UserName et Password génèrent l’événement PropertyChanged pour elles-mêmes et pour CanLogin. Un autre petit détail est le fait que Silverlight met uniquement à jour la source de la liaison de données bidirectionnelle lorsque l’utilisateur quitte le champ. Cela risque d’entraîner un retard perturbateur pour l’utilisateur. Par conséquent, je capture l’événement TextChanged des zones de texte pour forcer la mise à jour de LoginViewModel à chaque utilisation d’une touche. Toutes les interactions avec le serveur sont asynchrones et passent par les services WCF (Windows Communication Foundation). Pour la majorité des applications métier, cela signifie qu’un large pourcentage du comportement est asynchrone côté Silverlight et synchrone côté serveur. Le comportement asynchrone nécessite une requête pour effectuer une action et un mécanisme de rappel (callback) ou événementiel pour gérer l’exécution de l’action.

L’exemple d’application utilise la connexion comme exemple de processus. Il ne s’agit pas d’un véritable processus de connexion et il ignore les implications de sécurité pour se focaliser sur le mécanisme. La vue route la requête de connexion vers le modèle View via un simple modèle de commande. Le nom d’utilisateur et le mot de passe sont disponibles dans le modèle Vue du fait de la liaison de données bidirectionnelle. Le modèle Vue route la requête vers le modèle (service logique), lequel effectue un appel asynchrone au service WCF et définit un délégué callback.

Lorsque le service se termine, la tuyauterie WCF appelle la méthode callback dans le modèle. Cette méthode crée l’objet de données et génère un événement. L’argument pour cet événement contient l’objet de données. LoginViewModel capture cet événement et crée un UserViewModel. LoginViewModel génère un événement contenant UserViewModel comme argument.

La vue de connexion capture cet événement pour initier la navigation dans l’interface utilisateur en générant un événement spécifique à la vue. L’intérêt d’employer des événements est le fait de mettre l’accent sur ce qu’il se passe, ce que sait pertinemment chacun de ces acteurs. En revanche, ils ne savent pas ce qu’il doit arriver ensuite. Dans ce cas, un contrôle utilisateur de démarrage capture l’événement de vue de connexion et la remplace par la vue utilisateur. Votre application va probablement afficher une vue maître à ce stade. Même si ce cheminement à étapes multiples nécessite une certaine habitude, il maintient chaque élément isolé. Comme la vue de connexion, la vue utilisateur contient uniquement la liaison de données, la commande et le code spécifique à la technologie.