Je trouve des réponses mixtes à ma question sur le Web. Élaborer sur la question:
J'ai trouvé beaucoup de blogueurs et d'affiches de forum qui se contredisent mutuellement. Quelqu'un peut-il indiquer des sources définitives ou des preuves pour répondre à cela une fois et pour tous?
3 Réponses :
Vous devez ouvrir votre client par appel et le fermer immédiatement après. Si vous parcourez des doutes en utilisant IE dans un fichier SVC et regardez l'exemple qu'ils y sont là.
Que signifie «immédiatement après», cependant, dans le monde des appels de WCF asynchrones utilisés à Silverlight? Fermez-le après que je démarre l'appel asynchrone, ou fermez-le lorsque vous avez terminé? Si ce dernier, cela pose la question de ce qui se passe s'il n'est jamais terminé.
J'utilise Silverlight avec WCF depuis V2 (travaillant avec V4 maintenant), et voici ce que j'ai trouvé. En général, cela fonctionne très bien d'ouvrir un client et d'utiliser simplement un client pour toutes les communications. Et si vous n'utilisez pas le DUPLEXHTTBINDING, cela fonctionne également bien de faire exactement le contraire, d'ouvrir une nouvelle connexion à chaque fois, puis de le fermer lorsque vous avez terminé. Et en raison de la manière dont Microsoft a conçu le client WCF à Silverlight, vous n'allez pas voir beaucoup de différence de performance entre garder un client ouvert tout le temps contre créer un nouveau client avec chaque demande. (Mais si vous créez un nouveau client avec chaque demande, faites-vous être sûr que vous la fermez également.)
Maintenant, si vous utilisez le duplexhttbinding, c'est-à-dire si vous souhaitez appeler des méthodes sur le client. Sur le serveur, il est évident que vous ne fermez pas le client avec chaque demande. C'est juste bon sens. Cependant, ce que rien de la documentation ne vous dit, mais que j'ai trouvé absolument critique, c'est que si vous utilisez le duplexhttbinding, vous ne devez avoir qu'une seule instance du client ouvert à la fois. Sinon, vous allez courir dans toutes sortes de mauvais problèmes de délai d'attente qui vont être vraiment, vraiment difficiles à dépanner. Votre vie sera considérablement plus facile si vous avez une connexion.
La manière dont j'ai appliqué cela dans mon propre code consiste à exécuter toutes mes connexions via une seule classe statique de DataconnageManager qui jette une revendication si je Essayez d'ouvrir une deuxième connexion avant de fermer le premier. Quelques extraits de cette classe: La pièce gênante, bien sûr, si vous n'avez qu'une seule connexion, vous devez piéger lorsque cette connexion se ferme involontairement et essayer de Rouvrez-le. Et puis vous devez réinitialiser tous les rappels que vos différentes classes étaient enregistrées pour gérer. Ce n'est pas vraiment tout ce qui est difficile, mais il est ennuyeux de s'assurer que c'est bien fait. Et bien sûr, les tests automatisés de cette partie sont difficiles si non impossibles. . .
WCF Avez-vous des paramètres de configuration qui lui indique la durée d'attente d'un appel de retourner, ma pensée est que lorsqu'il ne complète pas dans le temps autorisé, l'ASYNCCLOSE le fermera. Par conséquent, appelez Client.AsyncClose ().
La réponse dépend probablement de votre service. Créer le proxy coûte cher, mais garder une trace de ce proxy unique et la gestion des erreurs peut être difficile.