Meilleures pratiques pour les requêtes et le service WCF

Question

Quelle serait la meilleure pratique dans le scénario suivant :

Il y a une grille qui sera remplie et qui doit être modifiée en fonction de chaque ligne. Par exemple, il y a une grille remplie de produits, puis en fonction de chaque produit, une des colonnes sera dynamiquement remplie. Est-il préférable de retourner du service toute la table productdetail et de l'interroger du côté client ou d'avoir une méthode sur le service qui retournera seulement les données nécessaires ? Dans ce dernier cas, s'il y a un nombre n de produits dans la grille, il y aura n requêtes pour cette méthode du service.

Mon dilemme est le suivant : pour certains utilisateurs, la table sera relativement petite et son envoi au client ne sera pas un problème, mais d'autres utilisateurs ont un nombre considérable de lignes à renvoyer (plus de 15 000).

Merci pour tout ce que vous pourrez nous apporter.

Answer 1

Vous pourriez faire en sorte que votre service implémente une sorte de pagination et permette au client de demander le nombre d'enregistrements qu'il souhaite (généralement un index de départ et un nombre, ou quelque chose comme ça). Vous pourriez plafonner la taille de la page à une certaine limite afin de ne pas avoir à servir une demande énorme.

En utilisant quelque chose comme cela, vous devriez être en mesure de trouver un bon équilibre entre le nombre d'appels effectués et la taille des données servies dans chaque requête.

Answer 2

Le sujet sur lequel vous êtes tombés est un sujet chaudement débattu de granularité en architecture orientée services . La SOA est comme un mammifère mystique discuté par des aveugles mais ce n'est pas vraiment le sujet.

En "meilleure pratique" La tendance est aux services à gros grains, qui s'éloignent de l'orientation objet. Considérez vos services comme des échanges de documents, dans lesquels vous mettez tout ce dont vous avez besoin pour faire avancer les choses.

Comme l'a suggéré Andy White, si les données deviennent trop volumineuses, il faut prévoir une sorte de filtrage ou de pagination.

Answer 3

On dirait que la latence du réseau est le problème ici. Si vous avez 100 produits et (disons) un temps d'aller-retour de 0,2 s, cela fait 20 secondes pour charger toutes les données. Réduisez vos appels de service autant que possible et, si nécessaire, remappez les données dans une structure plus appropriée dans votre client.

Edit : Une autre idée, si c'est possible dans votre situation, est de compresser les données entre votre client et le service. Jetez un coup d'oeil à ce message du forum . Vous verrez des gains importants si vous faites circuler des tas de XML.

Answer 4

Je suggère de créer une sorte de ViewModel sur le serveur pour adapter les données au client. C'est similaire à votre deuxième option ; cependant, ce n'est pas fait ligne par ligne. Il s'agit d'une opération par lot du côté du serveur qui prépare les colonnes afin que la vue n'ait pas besoin d'une logique particulière.

Je pense que la manipulation des données du côté client peut être délicate car il y a tellement de variables - navigateur, système d'exploitation, puissance de calcul. Vous contrôlez le serveur, alors exploitez ce que vous contrôlez autant que possible.

Bonne chance.