Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Happy Holidays !

Patientez quelques instants que le téléchargement de la petite application Silverlight ci-dessous se termine...

Ensuite passez la souris sur ma tête pour lire le message !

[silverlight:source=/SLSamples/JFetes2009/IlNeige.xap;width=480;height=320]

un peu de technique

Il faut bien que cela soit l'excuse de parler technique, au moins un peu...

Donc cette petite carte de voeux a été créée en utilisant l'exemple "Il neige" largement commenté ici (avec le source, voir "« Il neige » ou les boucles d’animation, les fps et les sprites sous Silverlight"). La transformation majeure est bien entendu de faire tomber des cadeaux et ma trombine de temps en temps à la place de certains flocons de neige.

Pour aller vite j'avoue que j'étais parti pour faire deriver les nouveaux sprites de la classe "Flocon" existante dont les instances sont multipliées pour créer l'effet de neige dans cette petite gestion de particules.

Pas d'héritage de UserControl

Trois fois hélas, créer un UserControl en héritant d'un autre n'est pas impossible sous Silverlight 3 mais c'est un peu sportif... Pour éviter d'entrer dans les manipulations nombreuses et hasardeuses permettant de contourner ce problème (temporaire on l'espère) j'ai utilisé la solution des interfaces.

J'ai donc créé une interface ISprite qui reprend les deux choses importantes pour la boucle d'animation : l'objet est-il passé hors zone (il doit alors être détruit) et l'action "Tombe" qui est appelée à chaque pas d'animation.

Le flocon original a été modifié pour supporter l'interface (ce qu'il faisant déjà avant) et la boucle d'animation (utilisant l'event de rendering de SL) a été modifiée pour utiliser des ISprite au lieu des Flocon originaux.

Ne restait plus qu'à créer autant de UserControl que de types de cadeaux qui peuvent s'afficher (un rouge, un vert, un bleu, plus ma bobine affublée d'une barbe rapidement dessinée par dessus). Chaque nouveau UserControl supporte ainsi ISprite. L'application fait des tirages au sort pour attribuer 25% de chances d'apparaitre à chacun des 4 sprites.

Améliorations diverses

Le reste est conforme à l'application "Il neige", à la création de chaque sprite celui-ci détermine une rotation et une taille aléatoire. Pour ma tête j'ai modifié la séquence pour que l'angle de rotation soit compris entre -45 et +45 degrés, de telle façon à ce que je ne me retrouve pas tête en bas ! Ce sprite a en outre été complété d'un phylactère annonçant "Joyeuses Fêtes" dont l'apparition et la disparition sont gérés via deux behaviors de type "GotoState". Lorsque la souris entre ou sort du contrôle ces derniers changent l'état du sprite et le message devient visible ou se cache avec une transition automatique gérée par le Visual State Manager.

Comme vous l'avez constaté lorsque la souris entre dans l'application une guirlande clignotante apparaît. Il s'agit d'une image vectorielle Illustrator passée (par simple copier / coller) vers Expression Design puis ensuite passée de la même façon sous Expression Blend à l'intérieur d'un nouveau UserControl. L'effet de chenillard est une animation réalisée "à la main" en mode "forever" en jouant sur l'opacité des bulbes et de leur reflet. Le contrôle est caché pour la souris ce qui fait qu'il est possible de cliquer sur ma tête "à travers" la guirlande bien qu'elle soit en premier plan.

Image de fond

Le logo E-naxos en 3D a été réalisé sous Swift 3D Version 6. Il a été transformé en Jpeg, car même si SL3 gérait la 3D la lourdeur d'une telle gestion ne s'imposait vraiment pas ici. C'est un fond statique et une image fixe est parfaite pour cela. En revanche un outil de 3D est nécessaire pour créer l'image !

Conclusion

Une façon ludique mais instructive de vous souhaiter à tous d'excellentes fêtes de fin d'années ...

Et en plus voici le code complet !

Amusez-vous bien et Stay Tuned !

Le code complet : IlNeige2010.rar (287,17 kb)

[EDIT] Voici le projet compressé en mode Zip, plus classique que le RAR que j'avais mis dans l'article : IlNeige2010.zip (290,57 kb)

Silverlight : Review des composants Cellbi

Il est assez rare, doux euphémisme puisque je pense que c'est la toute première fois, que je parle de composants tiers pour Silverlight. Il y a une bonne raison à cela : on peut tout faire soi-même, sauf l'infographie généralement, et je ne vois pas pourquoi il faudrait payer pour avoir ce qu'on peut faire en 5 minutes sous Blend. Reste l'infographie donc, mais quelque soit la qualité des composants qui existent à l'heure actuelle, c'est justement la partie faible. Quelques "thèmes" assez laids dans lesquels choisir pour avoir le même look que les copains qui auront acheté la même lib.

Bref, pour l'instant en tout cas, je ne vois guère de raisons valables d'acquérir des composants ou des thèmes Silverlight. Il y a tout de même une exception : certains effets très sympas qui demandent un peu plus de 5 minutes à être refaits.

Le célèbre caroussel est un exemple, mais ce n'est pas forcément le composant le plus important (tout le monde veut en mettre jusqu'à ce que ça lasse, par force). Les effets sur le texte sont beaucoup plus rares en revanches. Il y a déjà des années de cela j'utilisais Swish, sorte de clone de Flash, car justement il proposait de base des tonnes d'effets pour le texte et les images. Rien de tout cela dans les librairies classiques pour Silverlight.

Cellbi Software

... Sauf une exception. La librairie de Cellbi Software. 179 dollars, donc une misère, une version d'évaluation gratuite de 30 jours pour les dubitatifs. Et des tas d'effets très bien rendus, ce qui est rare aussi.

Même si le composant "principal" qui est proposé est un caroussel, celui-ci est très simple à utiliser. Il dispose d'une propriété ItemsSource, comme les Listbox, et on peut y binder ce qu'on veut : des images, des buttons, des UserControls, ... et même mélanger tout cela. Le composant gère des effets intéressants comme le floutage progressif, la possibilité d'ajouter une réflexion aux éléments, etc. Bref du bon travail, sans avoir à se rouler par terre, c'est pro, bien fait et facile à utiliser.

On trouve aussi une fenêtre qui peut être modale en option, même si cela fait un peu doublon avec celle de Silverlight, les options sont différentes et ce composant peut rendre service. 

Mais c'est surtout pour les effets sur les textes que je conseille cette librairie, enfin quelque chose d'un peu nouveau visuellement dans le monde Silverlight. De plus, les effets utilisés sont en réalité exploitables de façon différentes, on trouve même des composants spécialisés pour faire des transitions ou des effets de ce type. Les effets peuvent être mixés ou jouer en séquence, c'est bien fichu. On peut réaliser des slide shows attractifs, la librairies offrant pour les transitions des effets de ease-in/out un peu comme les animations Silverlight (elastic, quadratique, etc).

La librairie Cellbi n'est pas une grosse bibliothèque de composants, juste quelques uns et des effets. Mais elle ne coûte pas cher et offre un peu de nouveauté et un code qui semble sain et bien programmé. Les effets ont un rendu visuel tout à fait correct ce qui est très important dans un monde tel que celui de Silverlight qui se base avant tout... sur le visuel !

Un petit exemple 

Des tonnes d'exemples sont fournis, j'en ai bricolé un vite fait à partir d'un carousel sur des Buttons (ci-dessous). J'ai enlevé quelques boutons et j'ai ajouté deux dessins vectoriels (que j'ai encapsulé chacun dans un UserControl) afin de montrer que le mélange des genres fonctionne bien (en revanche l'équilibre visuel n'est pas terrible par force, c'est juste pour faire voir la souplesse du composant donc).

Lorsqu'on clique sur un élément du caroussel, celui-ci passe devant en tournant. Les éléments lointains sont diminués en taille, la perspective est respectée. L'ellipse de base, sa profondeur, ainsi que de très nombreux paramètres sont disponibles pour adapter tout cela à chaque besoin ponctuel. Il existe des commandes par code pour sélectionner un élément, ce qui, dans l'exemple ci-dessous est montré via les deux boutons flèches en bas (précédent et suivant).

Bien que le clic sur les objets soit capté par le composant pour les sélectionner, une fois un élément arrivé en position centrale (l'équivalent de l'item sélectionné dans une ListBox) il reste possible de cliquer dessus. Si c'est un bouton on peut donc programmer son Click, si c'est un UserControl on peut se brancher sur son LeftButton Up/Down. Il est parfois nécessaire de cliquer deux fois sur l'item pour passer du contrôle par le caroussel au contrôle du composant lui-même. Mon exemple manque peut-être aussi d'un peu de travail pour affiner ce genre de comportements. Dans l'exemple, si vous cliquez sur l'item sélectionné le TextBlock en bas à gauche affichera soit le Text (pour un Button) soit le nom de la classe (pour les UserControl).

Enfin, dans l'exemple ci-dessous je vous laisse voir l'effet de texte si vous cliquez sur le titre en haut. Sa position, sa taille, la couleur du fond, tout cela est loin d'être optimal pour rendre justice à l'effet utilisé. Il existe d'autres effets et tous les paramètres sont modifiables.

[silverlight:source=/SLSamples/Cellbi/CarouselBinding.xap;width=400;height=300]

Conclusion

La librairie de Cellbi est sympathique, rapide à prendre en main et propose des effets, notamment sur le texte, qui sortent un peu de l'ordinaire ce qu'il faut saluer. Pour environ 1000 de nos vieux nouveaux francs (179 dollars) cela permet d'ajouter un peu d'attrait dans un visuel. C'est pas cher comparé au travail nécessaire pour programmer ce genre de choses. Autant les librairies qui proposent des boutons ronds ou autres bêtises qu'on peut refaire en quelques minutes sous Blend me laissent de marbre, autant quand la qualité et l'originalité sont vendus bon marché il y a une vraie économie de travail pour le développeur, et là, cela en vaut la peine.

Ne vous attendez donc pas à une grosse lib bien grasse pleines de boutons ronds, de calendriers vus et revus ou de thèmes hideux. Juste quelques composants et des effets originaux.

A vous de juger, et le mieux c'est encore de tester la démo complète en ligne que vous trouverez sur le site de Cellbi Software.

Amusez-vous bien !

(et Stay Tuned, l'exemple pour M-V-VM arrive bientôt !)

MVVM, Unity, Prism, Inversion of Control…

Dans la série, presque culte, que je diffuse régulièrement et dont le titre serait “comment ne pas passer pour un idiot à la machine à café” la belle brochette de termes que je vous propose aujourd’hui a de quoi plonger le non initié dans une profonde perplexité !

Tous ces termes sont plus ou moins liés entre eux, les uns renvoyant aux autres ou les autres utilisant les uns.

MVVM ou plutôt M-V-VM

“Ah oui ! avec les tirets on comprend tout de suite mieux !” (Jean Sérien, lecteur assidu).

Model-View-ViewModel. Ca bégaye un peu mais c’est pourtant ça.

En réalité vous connaissez certainement le principe qui vient de M-V-C, Model-View-Controler, Modèle-Vue-Contrôleur. Une stratégie de développement visant à découpler le plus possible les données de leurs représentations. Sinon je vous laisse vous faire une idée, depuis dix ans au moins le Web est plein de pages présentant cette approche. Le billet du jour n’est pas d’aller dans les détails, juste de planter le décor avant d’aller plus loin dans d’autres billets.

Alors pourquoi MVVM plutôt que MVC ? C’est en tout cas le premier terme qui devient de plus en plus à la mode dans le monde WPF / Silverlight. Une réponse un peu courte je l’avoue… Mais même Prism (j’en parle plus loin) dans sa version 2 et qui, entre autres choses, présente cette stratégie ne l’évoque pas sous ce nom mais sous diverses autres formes. Autant dire que terminologiquement parlant, savoir ce que veut dire MVVM est un must de l’instant !

Donc M-V-VM est un modèle de développement, une façon de structurer l’écriture du code dont le but ultime est de séparer le Modèle (les données) des Vues (l’IHM ou l’UI), le tout en passant par un intermédiaire, le contrôleur qui s’appelle dans cette variante ViewModel (et pour lequel je ne trouve pas de traduction vraiment limpide).

La vraie question, légitime est : ce changement d’appellation cache-t-il un changement de rôle ? Les puristes vous diront bien entendu que oui, sinon ils n’auraient pas inventé un nouveau nom… Les pragmatiques dont je suis vous diront que lorsqu’on veut relancer un produit un peu trop connu mais toujours valable, on change son nom ce qui permet de communiquer à nouveau dessus plus facilement… Les méthodologistes sont des futés… Certains vont jusqu’à parler de parenté avec la pattern Presentation-Model, un peu comme d’autres vous expliquent que C# vient de C++ plutôt que de dire qu’il vient de Delphi. S’inventer des origines plus ou moins nobles (ou du moins qui le paraissent) est un jeu finalement très humain qui nous intéresse que peu ici.

Mais pour être totalement juste j’ajouterais qu’il y a en fait une véritable évolution de point de vue entre M-V-C, dont on parlait déjà du temps de Delphi Win32 et C++, et M-V-VM qu’on applique à WPF ou Silverlight. Par force le temps passe, les outils se sophistiquent et les pensées s’aiguisent. Donc, bien sûr, il y a quelques variations entre ce qu’on entendait par “contrôleur” dans MVC et ce qu’on entend par ViewModel dans MVVM. Mais, à mon sens, cela est mineur. D’ailleurs de nombreux forums proposent des threads à rallonge où des tas d’experts (autoproclamés) se déchirent sur ces nuances. Dépassons ces débats stériles.

Pourquoi MVVM est-il en train de s’imposer sous WPF / Silverlight ? Simplement parce que “out-of-the-box” Visual Studio et Blend ne permettent pas directement de vraiment séparer le travail entre les développeurs et les designers. Volonté pourtant clairement affichée de ces produits. Les outils eux-mêmes mélangent un peu des deux compétences (un peu plus de design dans Blend, un peu plus de développement dans VS).

Mais lorsqu’il faut écrire de vraies applications avec WPF ou Silverlight et qu’on a de vraies équipes à gérer, c’est à dire des informaticiens d’un côté et un ou plusieurs infographistes de l’autre, il faut bien convenir que sans une approche appropriée ça coince. Non pas que techniquement les outils (Blend, VS) ne sont pas à la hauteur, ni même que les langages (Xaml, C#, VB) ne sont pas bien étudiés. Au contraire. La faille est ici humaine et méthodologique.

En réalité tous les outils du monde, aussi bien faits soient-ils, ne peuvent permettre aux informaticiens l’économie d’une méthodologie bien pensée… Ce que Microsoft propose avec WPF / Silverlight, Xaml et le Framework .NET est très nouveau et il faut du temps pour maîtriser ces outils qui évoluent beaucoup en peu de temps. Dégager des stratégies de développement pertinentes est plus long que de créer un nouveau compilateur.

Or, si on regarde une fenêtre WPF ou une page Silverlight, on voit immédiatement qu’il existe du code-behind joint au fichier Xaml selon un modèle vieux de 15 ans (le couple de fichiers DFM/PAS des TForm de Delphi 1 en 1995 par exemple). La tentation est alors bien grande de coder l’action d’un click sur un bouton directement dans ce code puisqu’il est là pour ça ! Si c’est autorisé, c’est utilisé. Et malgré une séparation forte du code métier (ce qui suppose d’avoir fait cet effort) on se retrouve au final avec une interface qui contient du code qui en appelle d’autres (le code métier ou les données) voire pire, qui contient des petits bouts de traitement ! Autant dire que certains codes Silverlight ou WPF que j’ai audités récemment ressemblent comme deux gouttes d’eau au code spaghetti Delphi que j’ai audité dans les 15 dernières années… La vie n’est qu’un éternellement recommencement disent certains. Je n’ai pas cette vision nihiliste de l’existence, mais en informatique, hélas, cela se confirme !

Vade Retro, Satana !

En dehors de l’imbroglio qui résulte de cette situation, le code final de l’application est donc difficilement maintenable, intestable de façon cloisonnée (donc obligeant à des tests depuis l’interface par des testeurs ou des outils simulant un humain qui clique sur les boutons) et, comble du comble, il est en réalité presque impossible de séparer proprement le travail des informaticiens et des designers ! L’enfer brûlant s’ouvre alors sous les pieds des infortunés développeurs qui croyaient pourtant avoir “tout fait comme il faut”. Bad luck. On est loin du compte.

M-V-VM permet ainsi de régler plusieurs problèmes d’un coup : meilleure maintenabilité du code, vraie séparation entre code et interface, tests unitaires du code possibles sans même qu’il existe encore d’interface (ou totalement indépendamment de celle-ci), et enfin vraie séparation entre infographistes et informaticiens.

En pratique le fichier de code-behind ne sert plus à rien et reste vide. Les Vues (interface utilisateur) utilisent leur DataContext pour se lier à une instance du ViewModel qui lui sait utiliser le Model (les données). Grâce à cette notion de DataContext et au puissant Data Binding de Xaml on peut mettre en place une séparation bien nette avec, au final, peu de code en plus.

Reste le problème des événements de l’UI comme le simple clic sur un bouton. Comment le programmer sans code-behind ? Sous WPF la réponse est simple puisqu’il existe une gestion des commandes complète (le CommandManager et d’autres classes). L’interface ICommand est la base de ce mécanisme, les contrôles qui ont des propriétés de ce type peuvent donc être bindées au code des actions se trouvant alors placé dans le ViewModel, comme n’importe quelle autre propriété peut être liée via le binding.

Ce modèle est d’une grande élégance il faut l’avouer. J’aime plaisanter et je joke souvent dans mes billets, mais il ne faudrait pas croire que je passerais du temps à écrire un long billet sur un sujet futile ou une simple réinvention stérile de vieux procédés. M-V-VM est “la” façon de coder proprement sous WPF et Silverlight. Il n’y en a pas d’autres (d’aussi abouties pour l’instant en tout cas). Tout le reste ne peut que créer du code spaghetti. Cela peut choquer, vous paraître extrême dit comme ça, mais pourtant c’est la vérité…

C’est pourquoi je vous proposerais bientôt un autre billet abordant par l’exemple la stratégie M-V-VM.

Mais pour l’instant revenons deux secondes sur cette fameuse gestion des commandes de WPF. Et Silverlight ? Hélas malgré l’enthousiasme que vous me connaissez pour ce dernier et sa convergence avec WPF, il faut reconnaître que cette dernière n’est pas terminée. On le dit souvent, Silverlight est un sous ensemble de WPF, même si ce n’est plus tout à fait vrai. On avance aussi que le plugin est trop petit pour contenir tout ce qui fait WPF. C’est vrai. Mais comme je le disais dans un autre billet, avec une installation personnalisée du Framework ce dernier peut tenir dans 30 Mo. C’est bien plus gros que le plugin SL actuel. Mais j’ai joué pas plus tard qu’hier avec une application écrite en Adobe Air, et justement le download de Air fait environ 30 Mo. Pour un résultat tellement navrant que j’ai tout désintallé d’ailleurs. Alors d’ici quelques versions de SL, peut-être Microsoft (et les utilisateurs) accepteront-ils l’idée qu’un produit aussi bien ficelé puisse justifier les 10 ou 20 Mo de plus à télécharger (une fois) pour avoir enfin un équivalent absolu de WPF… Mais ce n’est pas encore le cas, force est de le constater.

Donc Silverlight pour le moment propose ICommand, l’interface, mais pas tout le reste qui fait la gestion des commandes sous WPF. De fait, dans Silverlight il faut ajouter un peu de code pour recréer cette dernière. C’est le but d’un petit framework comme “MVVM Light” qui se base sur les principes édictés dans Prism. Mais on peut inventer d’autres solutions.

Donc pour faire du M-V-VM avec WPF, tout est dans la boîte, avec Silverlight il faut ajouter une simulation, même minimaliste, de la gestion des commandes afin que ces dernières puissent être intégrées au ViewModel et que la Vue puisse être liée aux actions du ViewModel par un binding sur des propriétés de type ICommand.

Prism 2

Cela nous amène à évoquer Prism “patterns and practices : Composite WPF and Silverlight”.

Il s’agit d’une réflexion méthodologique dont les fruits se présentent sous la forme de conseils et d’applications exemples. Prism couvre de nombreux champs et propose des solutions élégantes.

Cela ne serait pas fairplay d’en parler en quelques lignes, c’est un travail d’une grande qualité qui ne se résume pas en trois phrases. Je vous conseille vivement sa lecture, rien ne peut remplacer cet investissement personnel.

Mais puisqu’aujourd’hui le but est de planter le décors, il aurait été tout aussi impardonnable de “zapper” Prism, surtout que certaines solutions permettant d’implémenter M-V-VM sous Silverlight y sont présentées.

Je reviendrai certainement un jour sur Prism, c’est d’une telle richesse que j’ai vraiment envie de vous en parler plus. Prism est incontournable, mais ne peut se résumer dans un billet. Si je trouve le moyen d’un tel tour de force alors je vous en reparlerai en détails. Mais le meilleur conseil c’est encore que vous le lisiez vous-mêmes…

Unity Application Block

Unity est un framework Microsoft qu’on trouve dans la série “patterns & practices”. Une mine d’or de la méthodologie sous .NET d’où provient aussi Prism dont je parlais ci-dessus.

Il faut noter que MS fait d’immenses efforts pour ouvrir la réflexion sur les méthodologies tout en tentant le tour de force de rendre ces cogitations tangibles. Lorsqu’on connaît un peu les méthodologistes pour les avoir fréquentés, toujours perdus dans leurs hautes sphères et rebutant à se “salir” les mains avec du code, on imagine à quel point l’effort de Microsoft est louable et tellement remarquable que cela mérite d’insister un peu sur la valeur de patterns & practices.

Ainsi, Unity, tout comme Prism, ne se contente pas d’être un gros pavé d’explications qui seraient réservées à une certaine élite. Unity se sont bien entendu des explications mais aussi du code qui permet d’ajouter l’action à la réflexion. Du bon code même. Des librairies utilisables pour simplifier le développement d’applications qui se conforment aux best practices. Je n’irais pas jusqu’à dire que les travaux présentés dans patterns & practices sont d’abord aisés, les cogitations méthodologiques réclament toujours un minimum d’attention, mais la volonté assumée de joindre la pratique et l’usage à la réflexion rend tout cela accessible à qui se donne un peu de temps pour lire et expérimenter.

Pour ce qui est de Unity, ce bloc se concentre sur la conception d’un conteneur “léger” et extensible permettant de faire de l’injection de dépendances (dependency injection).

De quoi s’agit-il ?

Comme indiqué en introduction de ce billet, tout ce dont je vous parle aujourd’hui tourne autour des mêmes besoins, de concepts proches ou qui se font écho les uns aux autres. L’injection de dépendances est une réponse à une série de problèmes qui se posent lorsqu’on désire séparer proprement des blocs de code tout en évitant de construire une “usine à gaz”.

Séparation de code, M-V-VM, Prism, ce sont autant de caméras placées autour d’une même scène. Des angles de vue différents, des manières d’entrer dans le sujet différentes, mais au final un but qui, s’il n’est pas commun, vise une même finalité. La conception d’applications souples, maintenables et extensibles.

Grâce à Unity vous disposez à la fois d’explications claires et d’une librairie permettant de gérer convenablement les injections de dépendances. Encore une terminologie “savante” pour des choses finalement pas si compliquées que cela. Mais pour en rajouter une couche disons que l’injection de dépendances n’est qu’une façon de gérer l’ “inversion de contrôle”.

Inversion of Control

“Pitié ! Arrêtez-le !” (Jean Peuplus, lecteur parisien)

On peut comprendre ce lecteur. Une telle avalanche ne risque-t-elle pas de tout emporter sur son passage, au risque de rendre ce billet contre-productif ?

La question mérite d’être posée, mais je fais le pari que vous tiendrez jusqu’au bout (qui est proche je vous rassure).

Le problème à résoudre

Pour info : j’utilise ci-après des parties de la documentation de Prism version octobre 2009

Vous avez une classe dont le fonctionnement dépend de services ou de composants dont les implémentations réelles sont spécifiées lors du design de l’application.

image

Les problèmes suivants se posent

  • Pour remplacer ou mettre à jour les dépendances vous devez faire des changements dans le code de la classe (classe A dans le schéma ci-dessus)
  • Les implémentations des services doivent exister et être disponibles à la compilation de la classe
  • La classe est difficile à tester de façon isolée car elle a des références “en dur” vers les services. Cela signifie que ces dépendances ne peuvent être remplacées par des mocks ou des stubs (maquette d’interface ou squelette non fonctionnel de code).
  • La classe contient du code répétitif pour créer, localiser et gérer ses dépendances.

Les conditions qui forcent à utiliser la pattern d’inversion de contrôle

  • Vous voulez découpler vos classes de leurs dépendances de telle façon à ce que ces dernières puissent être remplacées ou mises à jour avec le minimum de changement dans votre code, voire aucune modification.
  • Vous désirez construire vos classes de telle façon à ce qu’elles puissent dépendre d’implémentations inconnues ou indisponibles lors de la compilation.
  • Vous voulez pouvoir tester vos classes de façon isolée, sans faire usage des dépendances.
  • Vous voulez découpler la responsabilité de la localisation et de la gestion des dépendances de vos classes.

La solution

Il faut déléguer la fonction qui sélectionne le type de l’implémentation concrète des classes de services (les dépendances) à un composant ou une source externe à votre code.

Les implémentations

Il y a plusieurs façons d’implémenter la pattern d’inversion de contrôle. Prism en utilise deux qui sont l’Injection de dépendances (Dependency Injection) et le Localisateur de service (Service Locator).

image 

Injection de dépendances

L'injection de dépendances est un mécanisme qui permet d'implanter le principe de l'Inversion de contrôle. Il consiste à créer dynamiquement (injecter) les dépendances entre les différentes classes en s'appuyant généralement sur une description (fichier de configuration). Ainsi les dépendances entre composants logiciels ne sont plus exprimée dans le code de manière statique mais déterminées dynamiquement à l'exécution.

Le localisateur de services

Le localisateur de services est un mécanisme qui recense les dépendances (les services) et qui encapsule la logique permettant de les retrouver. Le localisateur de services n’instancie pas les services, il ne fait que les trouver, généralement à partir d’une clé (qui éviter les références aux classes réelles et permet ainsi de modifier les implémentations réelles). Le localisateur de services propose un procédé d’enregistrement qui liste les services disponibles ainsi qu’un service de recherche utilisé par les classes devant utiliser les dépendances et qui se chargent de les instancier.

Exemples

Même si les choses sont certainement plus claires maintenant (je l’espère en tout cas) il est certain que des exemples de code aideraient à visualiser tout cela. J’en ai bien conscience et j’ai prévu d’illustrer concrètement les principes expliqués dans ce billet. Toutefois en raison de la longueur de chaque exemple (nous parlons ici de techniques de découplement donc de nombreux fichiers et projets pour un seul exemple) il ne me semble pas raisonnable d’aller plus loin immédiatement. Laissons ce billet se terminer, et toutes ces notions tourner dans vos têtes avant de les appliquer !

Conclusion

Une terminologie ésotérique ne cache pas forcément des choses complexes. Le but de ce billet était de vous donner quelques clés pour mieux comprendre un ensemble de notions différentes mais participant toutes à une même finalité.

J’aborderai des exemples sous Silverlight très bientôt. Donc pour en savoir plus :

Stay Tuned !

TechDays 2010 à Paris, gratuit et incontournable !

Les Techdays sont généralement un grand moment, celles de 2010 devraient l’être encore plus ! Evénement gratuit sur trois jours du 8 au 10 février 2010 à Paris au Palais des Congrès, les Techdays 2010 c’est 3 conférences plénières, plus de 300 conférences techniques, des exposants, des experts, et plein de gens sympas à rencontrer !

Alors pas une seconde à perdre : cliquez vite sur ce lien suivant Techdays 2010 avant d’oublier de le faire !

clip_image002

Silverlight 4 : Do it yourself ! (adresses utiles)

Visiblement mon précédent billet annonçant Silverlight 4 et sa convergence avec WPF de plus en plus marquée a créé quelques remous chez certains lecteurs… Peut-être n’étaient-ils pas prêts à lire certaines évidences et vérités incontournables ? Peut-être ont-ils eu peur du changement qui s’opère sous leurs yeux mais qu’ils refusent de voir ? Peut-être ont-ils tout simplement mal compris mon billet ? Allez savoir !

En tout cas le meilleur moyen de se rendre compte de tout ça est de le vérifier par vous-mêmes !

Une citation

S’il n’en fallait qu’une ce serait celle-là…

Je ne suis pas le seul à penser ni à écrire que la convergence Silverlight / WPF va très certainement mener à la fusion totale des deux technos en une seule et que le nom qui restera sera Silverlight et non WPF. Une recherche sur Bing le montre assez vite notamment avec cette source que j’aurai pu citer directement si je l’avais connue avant d’écrire mon billet, une phrase à graver dans le marbre donc : “In the future, it is very likely that both Silverlight and WPF will be a single technology with a single codebase. After all, Silverlight was originally known as WPF/E (E as in Everywhere), and in an amazing 180 degree reversal of our usual approach, we took an ugly codename and created a great product name (Silverlight) from it.

Traduction : “À l'avenir, il est très probable que Silverlight et WPF deviennent une technologie unique avec une base de code unique. Après tout, Silverlight était initialement connu comme WPF/E (E comme dans Everywhere - Partout) et dans un incroyable renversement de 180 degrés de notre approche habituelle, nous avons pris un nom de code épouvantable et créé un nom pour un grand produit (Silverlight) à partir de celui-ci.

Extrait du billet “The Future of Client App Dev : WPF and Silverlight Convergence”.

Bon, après cette mise au point, passons à l’essentiel, à savoir comment jouer avec SL4 et vous rendre compte par vos propres moyens des avancées incroyables de cette nouvelle version :

Installer Silverlight 4

Un petit conseil personnel : Utiliser une machine virtuelle Virtual PC XP ou Vista (sous Windows 7 ça marche encore mieux). Tout ce qui est beta devrait toujours être installé sur des machines virtuelles pour ne pas polluer votre environnement de production. C’est en tout ce que je fais systématiquement. Pour SL4 j’ai une MV XP Pro avec 1 Go de Ram alloué et cela fonctionne parfaitement.

VS 2010

Tout d’abord il vous faut Visual Studio 2010 bêta 2 ou même Visual Web Developer Express 2010 beta 2. A noter que cette installation peut se faire sans aucun problème en parallèle de Visual Studio 2008 (il y a juste à faire attention si vous possédez déjà le SDK de Silverlight 3 sur votre machine).

Silverlight 4 beta Tools pour VS 2010

C’est le runtime de développement de Silverlight 4 avec support pour les projets SL4 sous VS2010 ainsi que le SDK SL4. Pour développer sous SL4 c’est le minimum vital.
Silverlight 4 Beta Tools for Visual Studio 2010

Les runtimes de test

Avec le téléchargement précédent vous n’avez besoin de rien de plus, mais si vous voulez installer le runtime Silverlight sur des machines de test non équipées de l’environnement de développement il faudra le télécharger, pour Windows ou pour Mac.
Windows Runtime ou Mac Runtime

Blend pour SL4

Même si VS2010 permet désormais de designer les applications Silverlight 4, Expression Blend reste (et restera) un outil incontournable (notamment pour les animations et le templating). Je vous conseille ainsi fortement de télécharger la version spéciale pour SL4.
Microsoft Expression Blend for .NET 4 Preview

Silverlight Toolkit

Lui aussi est devenu incontournable. Avec tous les contrôles supplémentaires qu’il offre ainsi que la gestion des thèmes visuels, il serait dommage de s’en passer.
Silverlight Toolkit

WCF RIA Services

La nature même de Silverlight oblige à travailler en n-tiers pour les données. Et plutôt que de tout faire à la main avec des services Web, autant utiliser les RIA Services (qui se fondent sur l’Entity Framework).
WCF RIA Services

La doc

Vous pouvez prendre connaissance de la doc en ligne de Silverlight 4 beta, toujours utile. Vous avez aussi la possibilité de télécharger le CHM en local : Offline CHM help Silverlight 4 Beta Documentation file download.

Apprendre, Comprendre et voir

Une fois tout le nécessaire installé vous trouverez certainement intéressant de faire un tour du côté des ressources suivantes qui vont aideront à faire le point sur les nouveautés de SL4.

Vidéos et exemples de code

Une série de vidéos couvrant les principales nouvelles features de SL4 (avec exemples en C# et en VB.NET).
Videos and Sample Code

Guides et labos

Pour explorer plus en profondeur, utilisez les Guides and labs.

Quoi de neuf ?

Un papier de John Papa : "What’s New" Whitepaper, et une video : "What's New in Silverlight 4 Beta" video

Les blogs

Les Silverlight Blogs sont une aide précieuse, n’hésitez pas à les visiter. Les blogs de certaines personne en particulier valent aussi le détour : Tim Heuer, Jesse Liberty, John Papa, Adam Kinney comptent parmi ceux qu’il ne faut pas louper en général.

Conclusion

A vous de jouer !

Convergence ou pas, Silverlight s’impose comme la technologie incontournable des prochaines années. Vous pouvez arrêter tout le reste. Si vous n’avez de temps que pour une techno, alors plongez vous dans Silverlight !