Blog de Vincent Lainé (dev01, phenixdotnet)

2
avril
2009

Mais au fait : Silverlight ça sert à quoi ?

Un article de dev01 Comments

C’est un peu la question que je me pose après quelques temps d?utilisation.

Il est vrai que je prend des risques : Je ne suis pas graphiste (mon gout des couleurs ne serait, au dire de certain, pas très développé ), je cherche à développer des sites web qui ont une forte interaction avec leurs environnements, qui sont dépend de données souvent volumineuses et surtout qui se focalisent sur les actions métiers et pas sur l’affichage.

Pourtant Silverlight à tout pour plaire : XAML, C# ou VB.NET et un Framework derrière.

Oui mais voilà : Le Framework Silverlight, bien que basé sur celui de .NET, a été tellement réduit qu?il ne reste plus rien

Passons sur le fait que l?utilisation d’Entity Framework avec Sliverlight est obligatoirement faite à travers des appels REST et que la moindre requête Linq est un vrai calvaire (sans parler du nombre de méthode d?extension qui ont été supprimé (comme Count() par exemple !). Au passage petite expérience personnelle : Je suis revenu aux services web WCF ?traditionnels? qui renvoi des « List(Of T) » pour accéder à mes données, ça marche bien mieux

Passons également sur le fait que le nombre de contrôle fournis par défaut est drastiquement réduit, pour résoudre cela nous avons le Silverlight Toolkit.

Mais franchement quand on veux faire un site en Silverlight qui ?fait des choses? alors là c?est la galère. Personnellement pour accéder à mes opérations métier je n?est pas besoin d?une super accélération graphique par la carte vidéo, ce qui me faut c?est la possibilité d’appeler un webservice externe en https ! Et comme je suis exigeant, il faut également que je puisse lui passer des informations de connexion de type NetworkCredential. Or dans Silverlight 2.0, WCF a tellement été taillé en pièce que l?on ne peux même plus fournir des Credential pour la connexion à un service web !

Et pour pousser le bouchon encore plus loin, j’aimerais également pouvoir réutiliser mes classes métier qui ne contiennent rien deux/trois fonctions sans être obligé de les extraire de leur librairies (compilé en 3.5) pour les mettre dans une librairie Silverlight.

Bref ma conclusion de tout ça c?est que Silverlight, c’est beau, c’est cool, c’est du XAML, mais alors c’est vraiment, vraiment pas fait pour être utilisé en entreprise. Et apparemment Silverlight 3.0 ne va changer la donne? De mon coté tant que la réutilisabilité de l?existant ne sera pas amélioré, je ne pense pas que je ne pousserais pas la technologie en avant. Je vais plutôt aller voir du coté du Framework MVC avec lequel j’ai eu l’occasion de jouer en version RC et qui m’avait beaucoup plus. Par contre si vous avez des vidéos, des images, et peu de code, alors oui Silverlight c’est le pied.

Une dernière chose : Si quelqu’un peut m’expliquer pourquoi la classe NetworkCredential et l’authentification d’un utilisateur sur un service web en général a été supprimé de Silverlight, je suis preneur.

4 Commentaires + Ajouter un commentaire

vpicchi 24 avril 2009 à 14 h 26 min

Bonjour Vincent,

Suite à ton article, je voudrais savoir si tu as reçu des informations concernant l’utilisation des credentials pour des web services externes dans Silverlight.

Est-ce que ce sera corrigé dans Silverlight 3.0 ou bien faut-il que j’arrête tout de suite mon projet web en silverlight qui va appeler énormément de web services et penser à développer sous un autre framework ?

Merci d’avance pour ta réponse.
nico-pyright(c) 3 avril 2009 à 9 h 34 min

Silverlight manque un peu de maturité à mon gout et effectivement, la réduction du framework est un frein important.
Par contre, ca augmente grandement l’interactivité et les temps de chargement.

Si tu as l’infrastructure derrière qui va bien, il est possible de faire pas mal de choses.

Mais bon, on est encore loin de la maturité d’un framework comme ASP.NET
dev01 2 avril 2009 à 9 h 40 min

Salut à toi.

La question n’est pas de choisir entre Javascript et Silverlight (je ne parle que de ce que je connais et je me garderais bien d’apporter un jugement sur Flex ;)), mais plutôt de parler des limitations (encore) trop importante de Silverlight pour être vraiment utilisable dans (pratiquement) tout les cas.

Personnellement je ne fait pas de javascript, ça m’énerve profondément :D. Par contre j’utilise le framework MVC couplé à l’AJAX (oui je sais c’est du javascript, mais il est « empaqueté » dans les libraires du Framework alors ça me va ) et avec ce couple « gagnant » je fait quasiment tout ce que je veux.

Reste que malgré les indéniables qualités et avantages de MVC+Ajax, tout n’est pas parfait, raison pour laquelle je me suis penché sur Silverlight. Avec toute les annonces, les articles et autres qu’il y a, mon raisonnement a été que c’était forcément génial. Aujourd’hui je suis obligé de le reconnaitre : C’est loin d’être aussi génial que ça.

Quant à la boule de cristal, je ne suis pas un spécialiste des technos web, je ne ferais aucune supposition sur l’avenir des technos
Philippe Vialatte 2 avril 2009 à 9 h 22 min

Salut,

perso, je n’ai pas tout a fait la meme approche…

On en parlait encore il y’a pas longtemps, pour un developpement web « standard », aujourd’hui, tu as le choix entre, d’un cote, utiliser du javascript (a la main ou JQuery/mootools/Dojo & co), ou utiliser Silverlight/Flex

Si tu pars sur du js, tu vas devoir maintenir ton appli, mais aussi la bibliotheque js, si tu changes le navigateur de reference, le rendu risque de ne plus etre bon, il va peut-etre falloir changer la version de la lib javascript-> autres bugs parce que l’API a change & co.

Si tu pars sur du SL/Flex, c’est a microsoft ou Adobe de fournir le plugin cote client et de s’assurer que le rendu sera le meme…toujours ca de moins a faire

Apres, que ce soit silverlight ou MVC, j’ai bidouille un peu, mais sans plus (pas le temps), mais je pense qu’a l’horizon 2010/2012, coder encore en javascript sera plus contre-productif quáutre chose…apres, a voir, ma noule de cristal est un peu encrassee