Silverlight et WCF ... pour être propre !

L'utilisation d'un canal de communication WCF par une appli silverlight nécessite un appel asynchrone, et donc, l'abonnement à l'évènement blablablaComplete.

Lors de l'appel de la méthode blablabla, nous pouvons passer en paramètre l'objet proxy afin d'effectuer des opérations de nettoyage (pour être plus propre) :
CloseAsync( ) et le désabonnement à l'évènement.

Exemple :

// méthode sur l'évènement complete (sous la forme d'une expression lambda) EventHandler methodComplete = null; // Proxy pour l'appel WCF SrvDatasClient proxy = AppDataHelper.GetProxy(); // définition de la méthode lambda methodComplete = (ssender, ee) => { // traitement du retour //ee.UserState contient le proxy (ee.UserState as SrvDatasClient).SaveCompleted -= methodComplete; // plus propre (ee.UserState as SrvDatasClient).CloseAsync(); // super plus propre }; proxy.GetAllCompleted += methodComplete; proxy.GetAllAsync(proxy); // appel ou je passe en param le proxy

C'est toujours plus propre de fermer ce que l'on utilise ...

Silverlight 2 et URL

En Silverlight 2 (comme en WPF d'ailleurs), il est fortement conseillé de créer des styles, et de mapper ces derniers aux composants concernés (via leur balise style et le mécanisme de resource statiques).

Dès lors, ces styles sont créés soit dans les ressources du usercontrol concerné, soit dans les ressources de l'application (App.xaml)

Dans le cas d'images (incorporée dans l'assembly comme ressource) il est d'usage d'utiliser les url's absolues pour permettre la récupération des images, quel que soit le niveau du sous namespace, ou sous répertoire du xaml du user control concerné.

Ce chemin se présente de la sorte :

/nomDeLAssembly;component/blablabla

où blablabla correspond au chemin de l'image.
Si le chemin de l'image dans le projet est Images/toto.png
mon chemin sera :
/nomDeLAssembly;component/Images/toto.png

@+

Silverlight 2, WCF et les FaultException

Lorsque une équipe travaille en Silverlight, il est nécessaire de communiquer avec un proxy (serveur) pour disposer de données et interagir avec elles.
Pour se faire, nous pouvons utiliser les objets WebRequest ou WebClient (tuto : http://bdevuyst.developpez.com/tutoriels/silverlight/S2-interagir-avec-son-serveur/).

Nous pouvons également utiliser WCF (Windows Communication Fundation). Pour rappel, cette technologie permet de ne maitriser qu'une seule syntaxe (en C#, par exemple), et un fichier de paramètres permettra à WCF de savoir quel est le protocole à utiliser pour les échanges (WebService, NetPipes, ...).

Lorsque l'on manipule du WCF, les exceptions rencontrées sur le serveur peuvent être transférées au client grâce à la classe FaultException (Il s'agit d'une Exception qui peut être sérialisée vers un client).
Tout autre Exception (dérivant de System.Exception) se voit arrêtée par WCF côté serveur.
En effet, pour des raison de sécurité, une System.Exception ne peut traverser WCF.
(Elle contient trop d'informations sur l'architecture de l'application - stacktrace par exemple).

Suite à un souci (l'explication est à trouver ici : msdn), ces erreurs ne peuvent être remontées vers le client Silverlight 2 (ce sera peut être le cas en version 3).

Dès lors, pour pouvoir gérer, côté Silverlight, les exceptions éventuelles de l'application serveur, il faut être un petit peu sioux !

Voici le lien d'une solution Visual Studio 2008, proposant une réponse à ce problème :
ftp://ftp-developpez.com/bdevuyst/tutoriels/silverlight/S2-gestion-exception-wcf/SilverlightApplicationGstException.zip

Globalement, voici le mécanisme :

La solution est divisée en 3 projets :
- Le projet Web qui héberge l'application Silverlight et un Service WCF (.svc),
- Le projet Silverlight,
- Un projet bibliothèque de classe qui "simule" une autre couche, qu'utilise le Service WCF,

1. L'application Silverlight appelle le point de terminaison WCF, (derrière le bouton),
2. L'application WCF traite la demande, cherche à obtenir les données, et une exception se produit... (pas de chance ;) )
3. La couche WCF catch l'exception, et retourne un objet d'un type particulier
4. Cet objet retourné est la clé du mécanisme

Il s'agit d'une classe générique qui contient 3 propriétés :

• Message : Correspond au message de l'exception générée, vide si le traitement s'est bien passé,

• StackTrace : Pour le debug (dans le cas de symbole de debuggage absent, ce champ est vide)

• ObjetAttendu dont le type est précisé lors de la déclaration de la variable. Cette dernière contiendra l'objet attendu si aucune exception ne s'est produite pour le récupérer.

L'application Silverlight récupère alors un objet qui contient les trois propriétés, et peut donc déterminer si une exception s'est produite, et si un résultat est exploitable.

Je vous invite à télécharger les sources pour bien saisir le mécanisme...
Lien des source de la solution Visual Studio 2008 :
ftp://ftp-developpez.com/bdevuyst/tutoriels/silverlight/S2-gestion-exception-wcf/SilverlightApplicationGstException.zip

@+