[WCF] Bonnes pratiques

Version imprimable

09/11/2015, 14h00
Kropernic

[WCF] Bonnes pratiques

Hello,

Je vais prochainement être amené à développer une application client/serveur en utilisant la techno WCF.

N'ayant jamais utilisé cette techno, je recherche donc des conseils concernant les bonnes pratiques à respecter.

J'ai joué un peu avec en suivant un tuto pour faire un chat mais rien de bien folichon.

La question principale que je pose est de savoir s'il vaut mieux laisser le client connecté au serveur non-stop ou s'il faut le déconnecté après chaque demande.

Y a-t-il une limite au nombre de canaux ouverts ?
09/11/2015, 14h31
DotNetMatt

Citation:

Envoyé par Kropernic

La question principale que je pose est de savoir s'il vaut mieux laisser le client connecté au serveur non-stop ou s'il faut le déconnecté après chaque demande.

Y a-t-il une limite au nombre de canaux ouverts ?

Oui c'est comme pour ADO.NET, il vaut mieux ouvrir puis fermer dès qu'on a terminé.

Dans certains scénarios, type batch, tu peux aussi mettre tes opérations en queue, puis ouvrir ta connexion, les exécuter et enfin fermer... L'idée derrière c'est que dès que tu n'as plus besoin de la connexion, tu dois la fermer, exactement comme en SQL.

1 canal = 1 connexion, et il y a une sorte de connection pool (comme en SQL) qui s'occupe de gérer les connexions. A noter, les connexions ne sont pas thread-safe ! Il n'est en général pas conseillé de réutiliser les canaux, il vaut mieux en créer un à chaque fois que tu en as besoin. Ce n'est pas coûteux. L'opération la plus coûteuse est de créer la ChannelFactory, qu'il vaut mieux garder en cache pour la réutiliser lorsqu'on veut créer un canal.
09/11/2015, 15h15
Kropernic

Comme quoi, j'ai bien fait de poser la question aussi sur le forum.

Avant de venir ici, je suis allé faire un tour sur le chat. Là, on m'a dit qu'il valait mieux laisser ouvert et fermé une fois tout fini.

Sinon, si je compare avec le tuto du chat, là, on laisse effectivement ouvert. Mais WCF a un timeout par défaut à 10 minutes en cas d'inactivité. Mais le chat est p-e un cas particulier.

L'application que je vais devoir faire devra aller récupérer des informations de tickets de caisses. Donc une fois la requête envoyée et la réponse reçue, c'est vrai que je n'aurai plus besoin de la connexion avant quelques minutes. Donc autant la fermer. C'était ma première intuition et tu la confirmes. Donc ça c'est bien.

D'autres choses auxquelles il faut faire attention avec WCF ? Des trucs particuliers qui ne sont pas forcément intuitifs ? (le genre de truc qu'on se dit après coup "fallait le savoir!")
09/11/2015, 15h26
DotNetMatt

Citation:

Envoyé par Kropernic

Mais le chat est p-e un cas particulier.

En effet par exemple si tu utilises des mécanismes tels que full duplex ou autre, ca peut varier. Je répondais d'une manière générale pour des scénarios classiques ;)

Citation:

Envoyé par Kropernic

D'autres choses auxquelles il faut faire attention avec WCF ? Des trucs particuliers qui ne sont pas forcément intuitifs ? (le genre de truc qu'on se dit après coup "fallait le savoir!")

Avec WCF il y a plein de choses à savoir, donc difficile de te faire liste exhaustive, le mieux c'est de se casser les dents dessus ;) Un truc quand même très important, les exceptions ne vont pas remonter jusqu'à ton client, du moins pas toutes. Donc le débuggage peut être compliqué et lourd parfois... En gros la plupart des fois où tu n'as pas de message très précis, il faut que tu regardes du côté du serveur.
09/11/2015, 15h33
Kropernic
Le serveur devrait à priori (pas encore vraiment fait d'analyse) être trèèèèèèès simple.

Il devrait se contenter de
1. Recevoir :
- un numéro de magasin
- une date
- un numéro de caisse
- un numéro de ticket
2. Faire la requête vers le serveur approprié (déterminé en fonction du numéro du magasin) pour récupérer les infos du ticket
3. Renvoyer le ticket vers le client (ce sera une classe qui contiendra toutes les infos nécessaires)

Donc niveau erreur côté serveur, ça devrait aller ^^.

Ce que je redoute le plus, ce sont les problèmes de communication entre clients et serveur car je n'y connais pas grand chose en réseau et quand bien même, je n'ai pas la main dessus pour pouvoir administrer quoi que ce soit...
10/11/2015, 09h46
DotNetMatt

Citation:

Envoyé par Kropernic

Donc niveau erreur côté serveur, ça devrait aller ^^.

Tant mieux alors ! C'est souvent ce que je me dis aussi mais bizarrement il y a toujours quelque chose qui ne marche pas :mouarf::mouarf:

Citation:

Envoyé par Kropernic

Ce que je redoute le plus, ce sont les problèmes de communication entre clients et serveur car je n'y connais pas grand chose en réseau et quand bien même, je n'ai pas la main dessus pour pouvoir administrer quoi que ce soit...

Ca tu peux (et tu dois :aie:) le planifier avec ton équipe réseau. Pour chaque serveur il faut recenser la liste des ports nécessaires (ex. 80 pour HTTP, 443 pour HTTPS, 1433 pour SQL Server, etc.) et tu leur envoie en leur demandant s'il y a quelque chose (firewall, reverse proxy, etc.) qui puisse bloquer les communications entre les machines sur ces ports.
10/11/2015, 09h51
Kropernic

Citation:

Envoyé par DotNetMatt

Tant mieux alors ! C'est souvent ce que je me dis aussi mais bizarrement il y a toujours quelque chose qui ne marche pas :mouarf::mouarf:

Oui, c'est tristement souvent mon cas aussi. Mais en général ce sont des petites choses assez vite résolues.

Citation:

Envoyé par DotNetMatt

Ca tu peux (et tu dois :aie:) le planifier avec ton équipe réseau. Pour chaque serveur il faut recenser la liste des ports nécessaires (ex. 80 pour HTTP, 443 pour HTTPS, 1433 pour SQL Server, etc.) et tu leur envoie en leur demandant s'il y a quelque chose (firewall, reverse proxy, etc.) qui puisse bloquer les communications entre les machines sur ces ports.

Je devrais avoir les accès nécessaires (les demandes firewall ont déjà été envoyées) pour faire les tests de communications dans la semaine. Une fois ces tests concluants, je pourrais planifier le vrai dev. Enfin, faire l'analyse déjà.