0

Je suis coincé avec un peu d'un problème ennuyeux en ce moment. J'ai une application Silverlight 4 (qui exécute OOB par défaut). Il utilise WCF avec net.tcp comme moyen de communication avec le serveur. Le client utilise une instance centrale du proxy client wcf. Tant que tout fonctionne sur le serveur, tout va bien.Le serveur net.tcp de WCF se déconnecte - comment gérer correctement du côté client?

Si je tue le serveur au milieu de tout, je me noie dans une avalanche d'exceptions côté client (connexion perdue, canal défectueux etc etc).

Maintenant, je cherche un moyen de gérer cela de manière propre et centralisée (si centralisé est possible). L'application SL a un objet client central dans App.cs (public static MyClient Client {get; set;}), qui est initialisé au démarrage de l'application.

Une idée de comment gérer correctement les problèmes de connectivité sur l'objet client?

Répondre

1

Je pense avoir trouvé une solution réalisable - mais non centralisée. Au lieu d'encombrer le code avec des blocs try/catch, tout ce dont il semble avoir besoin est une vérification nulle de la propriété event.Error. Si quelque chose est arrivé à la connexion, cette propriété n'est toujours pas nulle. Les exceptions ne sont levées que si vous essayez d'accéder à event.Result.

Ce n'est peut-être pas la plus belle solution, mais elle semble fonctionner jusqu'à présent.

Peut-être il y a une façon plus élégante mais ...

2

Vous mentionnez que vous utilisez une instance centrale du proxy client WCF.

Si tel est le cas, alors lorsqu'une erreur de serveur survient, le proxy passe à l'état Faulted. Pour garder les choses centralisées, vous pouvez convertir le proxy client en ICommuicationObject et attacher un gestionnaire d'événement à l'événement Faulted qui remplace le proxy défaillant, avec un nouveau proxy lorsque l'événement se déclenche.

Les avertissements habituels concernant la sécurité des threads pour l'accès centralisé aux ressources s'appliquent!

+1

En fait, je viens de trouver ce blog-post qui fait exactement cela: http://nahidulkibria.blogspot.com/2008/05/knowing-when-wcf-service-in-fault-state.html –