Dossier Silverlight : Application de l’approche Modèle-Vue-VueModèle

Réponse : Silverlight représente un nouveau modèle car il offre une interface utilisateur totalement isolée, laquelle peut seulement interagir avec le serveur de manière asynchrone. Ainsi, c’est un peu comme une application Web. Mais il exécute également votre code côté client au sein du CLR, au lieu d’un langage de script basé sur le navigateur, tel que JavaScript. Cela ouvre la porte à la création d’interfaces utilisateurs nettement plus riches, similaires à une application client enrichie, mais avec moins de travail. Les meilleures applications Silverlight métier sont basées sur une nouvelle approche intellectuelle et non sur la transposition des habitudes acquises avec les applications WinForms ou ASP.NET. Même si l’exécution se déroule dans un CLR .NET côté client, ce n’est pas le même CLR et vous avez en fait des assemblys totalement distincts s’exécutant sur votre plate-forme Silverlight avec un sousensemble du CLR .NET disponible.

La présentation de ce mode bi-plate-forme et la combinaison de l’accès au service asynchrone isolé avec un environnement de programmation riche peut suffire à compliquer les questions d’architecture. Toutefois, l’introduction de Silverlight coïncide avec deux autres changements majeurs : la décomposition des applications en unités testables indépendantes et le déplacement des comportements des objets vers les services logiques. Le développement orienté vérification (cf. l’encadré « Développe – ment orienté vérification ? » dans cet article) explique pourquoi la création d’applications plus granulaires avec des limites définies présente de nombreux avantages et démontre qu’une application testable présente des atouts allant bien au-delà de la testabilité.

La conception de vos applications Silverlight constitue une bonne approche pour introduire ces techniques. Je vais expliquer une approche architecturale qui répond à ces problématiques et intitulée Modèle-Vue-VueModèle (ou MVVM, Model-View-View Model en anglais). Ayez à l’esprit qu’il s’agit d’un espace dynamique où les meilleures pratiques Silverlight émergent progressivement. Mon objectif est de clarifier l’approche générale ; les détails pertinents pour votre application peuvent différer légèrement.

L’approche décrite ici exploite les possibilités de Silverlight et optimise la réutilisation du code. Vous pouvez reconstituer le même objet avec des données et un comportement sur les côtés Silverlight et .NET de l’application, mais je pense qu’il est plus simple d’utiliser des objets se limitant aux données, lesquels sont souvent appelé Data Transfer Objects (DTO) ou, tout simplement, objets de données. Les classes contenant les services logiques peuvent employer ces DTO et seront compilées dans vos applications Silverlight et .NET, sans avoir besoin de reconstituer les classes avec les données. Les services logiques fournissent un environnement dans lequel vous pouvez gérer votre application sous la forme d’une série d’éléments granulaires.

Grâce à des outils de composabilité tels que Managed Extensibility Framework (MEF), vous pouvez réunir tous les acteurs qui souhaitent participer à la phase de validation ou d’autorisation. La figure 1 montre une subdivision logique possible du pipeline d’application Silverlight. La ligne orange représente la limite du service physique. Les lignes en pointillé indiquent un modèle pour séparer les unités logiques en différents assemblys et j’ai surimposé les noms d’assembly de l’exemple d’application. La décision concernant les limites d’assembly est susceptible de donner lieu à des discussions. J’opte pour plus d’assemblys afin d’appliquer l’isolation et d’améliorer la composabilité, ainsi que la testabilité. Il est également plus facile de combiner des assemblys ultérieurement que de les séparer.