Retour sur la PDC : Multi-targeting avec The Portable Library

 

 

Retour sur la PDC : Multi-targeting avec The Portable Library

  • Comments 2

Comment développer une application déployable sur plusieurs plateformes en capitalisant le maximum de code ? On pense souvent à l’intérêt de la factorisation durant la phase de développement, pour ne pas coder 2 fois le même fonctionnel. Mais il est peut-être encore plus grand pendant la phase de maintenance de votre application, où chaque modification doit être appliquée et testée sur le code correspondant à chaque plateforme. C’est évidemment une source d’erreur importante sans parler du côté rébarbatif de la chose et de la perte de temps qu’elle entraine.

La session de Shawn Burke à la PDC donne l’occasion de reparler de ce sujet qui tient à cœur beaucoup de développeurs, moi y compris Sourire .

1.     Les cas d’application

De nombreuses applications client-serveur du domaine pro sont aujourd’hui disponibles en version « lourde », avec des fonctionnalités complètes, mais également en version web (ou pour le téléphone), avec parfois des fonctionnalités allégées. Par-exemple, une application WPF permet d’éditer, d’ajouter du contenu, d’accéder facilement aux ressources de sa machine, et la version Silverlight permet la consultation du contenu et quelques réglages simples.

Dans cette configuration, l’application est souvent d’abord développée en WPF et le client web - qui n’est finalement qu’un sous-ensemble fonctionnel de l’existant - est ajouté par la suite. Ou une application est développée en Silverlight, et son homologue sur Windows Phone 7 ensuite, etc...

Le but est donc de réutiliser un maximum de code, principalement pour les couches métier qui resteront inchangées que l’écran soit un 3” ou un 27” .

Quelques points clés pour aider à gérer au mieux ce contexte d’application multi-plateforme :

2.     Utilisation de l’architecture 3-Tiers MVVM

La première étape pour tendre vers une factorisation massive et propre du code est l’utilisation d’une architecture N-tiers. Le choix se porte assez naturellement sur MVVM qui permet le découplage du modèle, de ses cas d’utilisation ainsi que de la vue. L’approche MVVM permet une interaction facilitée aux technos fournissant un mécanisme de Binding comme WPF et Silverlight.

Même si les couches “Vue “diffèrent selon les plateformes, on pourra espérer partager les couches Model et ViewModel autant que possible.

WPF Apps With The Model-View-ViewModel Design Pattern

3.     Maximiser la compatibilité côté XAML

Quid du partage de la couche « Vue » ? Silverlight et WPF utilisent tous deux le XAML avec une syntaxe de plus en plus proche.

Pour gagner du temps de développement mais aussi de maintenance, autant tenter d’utiliser une syntaxe qui soit la plus compatible possible entre les deux technos. Cette approche peut avoir des détracteurs et le but n’est pas forcément de partager tous les fichiers xaml (d’ailleurs ce sera certainement impossible J ). Mais à partir du moment où une vue existe et fonctionne, pouvoir réutiliser le maximum de xaml apporte un gain de productivité non négligeable, que ce soit lors de la conception, mais aussi et surtout pour la maintenance de l’application.

C’est moins vrai avec Silverlight pour WP7 où la couche vue sera spécifiquement adaptée à un écran de l’ordre de 3 pouces avec une ergonomie à la Metro et donc très différente des autres plateformes.

A ce compte-là, je vous propose quelques pointeurs bien pratiques qui aident à définir les syntaxe XAML qui fonctionnent aussi bien en WPF qu’en Silverlight ou qui vous permettront de connaitre les spécificités de chaque plateforme en terme de XAML.

4.     Le partage d’assemblies et de fichiers

Le partage de code peut s’envisager sous différents angles :

  • Partage de projets
  • Partage de fichiers source
Partage de projet

Qui dit partage de projets dit partage d’assemblies. Une application Silverlight ne peut référencer que des assemblies de type Silverlight. Par-contre, il est possible de référencer une assemblie Silverlight (utilisez Silverlight 3) depuis un projet WPF. Pour cela, l’assemblie Silverlight ne doit pas contenir de code spécifique à l’UI Silverlight, mais uniquement des classes métier, et le référencement doit sur faire sur les binaires et non sur les projets.

Partage de fichiers source

Dans Visual Studio, il est possible d’ajouter des fichiers sous forme de liens. Ainsi, plusieurs projets peuvent référencer le même fichier facilement mais évidemment c’est une pratique assez risquée puisque pas de versionnement du code comme c’est le cas pour les assemblies.

 

image

Le gros inconvénient de ces deux approches est que vous ne maitrisez pas du tout avec quelles plateforme le code que vous écrivez sera compatible. Vous développez une assemblie Silverlight, donc vous aurez accès aux espaces de noms et assemblies Silverlight-compliant. C’est votre responsabilité de développeur, de vous documenter, de tester et de n’utiliser que des objets compatibles dans les différents mondes. Or c’est très contraignant de savoir ce qui est réellement compatible entre les différentes plateformes (accès au système de fichier, sérialisation, …).

C’est là qu’intervient le nouveau type de projet “Portable library” pour Visual Studio qui est prévu pour le début d’année prochaine. 

5.     Le nouveau type de projet Visual Studio : Portable Library

Le but est de “typer” un projet librairie de classe comme une librairie “portable”. Dans cette librairie, vous n’aurez accès qu’aux espaces de noms qui sont communs aux 3 plateformes .Net/Silverlight/Phone. De plus, la Portable Core Lib se veut être le minimum fonctionnel sur toute plateforme et c’est pourquoi elle ne contient pas directement l’intersection des plateformes existantes : elle doit également être valable pour les plateformes à venir.

image

Vous serez évidemment guidés par l’Intellisense et contrôlés par la compilation.Cela force le développeur à ne pas écrire de code spécifique à une plateforme donnée dans ce projet.

Cette librairie peut ensuite être utilisée par des application .Net, Silverlight, Windows Phone. Dans la première version de la Portable Library, les espaces de nom disponibles seront assez réduits.

image

Mais au fil des versions, ils seront complétés pour arriver à un vrai sous-ensemble fonctionnel commun et minimal à toutes les plateformes.

image

Dans la roadmap, la portable library est prévue pour début 2011.

image

Cela nous aidera côté développement à être explicite en terme de plateforme ciblées dans la création de nos librairies. Mais pratique également pour la maintenance en nous empêchant d’employer un fonctionnel donné dans une librairie dite portable qui ne serait pas supporté sur toutes les plateformes ciblées par le projet.

La Portable Library règle la question du référencement statique des librairies. Néanmoins, il serait intéressant que l’on puisse déterminer dynamiquement le comportement (ou l’activation) de telle ou telle fonctionnalité suivant la plateforme sur laquelle elle s’exécute. C’est là qu’interviennent les mécanismes d’injection de dépendances.

6.     L’injection de dépendances : mettre en commun un comportement quand on ne peut pas capitaliser le code

Grâce à MEF (Managed Extensibility Framework) ou Unity, vous pouvez charger des assemblies dynamiquement, sur la base d’un comportement défini par une interface. Votre application chargera les assemblies que vous avez déployées sur votre plateforme, plutôt que celles que vous auriez référencé dans votre projet.

Dans ce cas, vous capitalisez non pas du code, mais un comportement générique (signature) grâce aux interfaces.

7.     Et aussi

Modélisez, développez en OO

La modélisation et la conception orientée objet de votre application conditionne très fortement la réussite de votre multi-targeting. Pensez à découpler, pensez fonctionnel…

La compilation conditionnelle

La compilation conditionnelle (#if SILVERLIGHT…#endif,  …) peut également permettre de sauver la mise, dans des situations désespérées, mais elle n’est pas à recommander en règle générale.

En effet, c’est à votre architecture en couche et à votre modèle de conception objet de spécialiser les différentes approches et d’apporter la souplesse nécessaire pour garantir une bonne lisibilité et maintenabilité du code.

Les classes partielles, les méthodes d’extension

Permettent de rajouter du comportement à une classe sans modifier le code existant.


Le multitargeting est un sujet passionnant qui touche une majorité de développeurs. Je reviendrai très bientôt sur ce sujet, pour la sortie de la Portable Library !

Leave a Comment
  • Please add 1 and 3 and type the answer here:
  • Post
  • dans ce cas,si j'ai bien compris, il sera possible de développer en XNA et après en X360 et

    Winmo7?

  • Oui dans le sens où ce sera plus simple de partager des assemblies communes. Du coup il faut penser à bien découpler ses couches lors de la conception.

    Cordialement,

    Stéphanie

Page 1 of 1 (2 items)
Page 1 of 4 (88 items) 1234