Callback ou « le retour de la programmation spaghettis »

Bonjour,

Un titre un petit peu provocateur, je le concède. Mais est-ce une réalité ou est-ce moi qui n’utilise pas correctement les callbacks ?

Voici, sur base d’un exemple le problème et sa résolution spaghetti.

Dans une application, j’ai des utilisateurs ASP (avec login et mot de passe) qui sont associés à des individus (Pierre, Paul ou Jacques). Chaque individu fait partie d’un Magasin.

Il m’importe de connaitre le numéro ou le nom du magasin dans lequel travaille celui qui vient de se loguer.
Après qu’il ait entré son mot de passe, je dois faire un premier callback qui me retrouve l’identifiant ASP en fonction du nom de l’utilisateur ASP.
Dans CallBack_identifiantASP, je dois faire un second callback qui me retrouve l’identifiant de Pierre, Paul ou Jacques en fonction de l’association (foreign key) entre « individu » et utilisateur ASP.
Ensuite, comme l’individu me donne aussi l’identifiant du magasin dans lequel il travaille, je n’ai plus qu’à faire un troisième callback qui va me retrouver par exemple le nom du magasin.
L’inconvénient de ces callbacks successifs est que le code est disséminé dans l’un ou l’autre de ces callbacks plutôt que d’être structuré en un seul endroit.

Il en va de même si je veux par exemple enregistrer 3 achats sur une carte de fidélité d’un client, je dois :
Après sélection du client, callback pour voir s’il a déjà une carte de fidélité.

Si NON (pas encore de carte), je dois la créer et refaire un callback pour connaitre l’identifiant de la nouvelle carte (j'ai souligné pour savoir si dans ce cas il n'existe aucun moyen de récupérer l'identifiant nouvellement créer sans faire un callback). Et enfin je peux mettre mes achats dessus.

Si OUI(déjà une carte), je dois faire un callback pour savoir s’il n’est pas pleine..

Merci d'avance pour vos commentaires.:)

Pour le premier cas, pourquoi ne pas tout faire d'un coup dans le même appel au serveur?

Dans le second cas, c'est plutôt la logique de l'appli à revoir.

Edit: En relisant le post, t'es sur que c'est dans le forum Silverlight que tu veux poser ta question?

Pour le 1er cas, comme le dit PitMaverick78, pour ne pas faire une seule fonction qui te ramène tous les éléments dont tu a besoin plutôt que 40 petites ?
Genre un GetUserInfo() qui te renvoie un objet User avec les infos de la personne dessus ?

Pour le deuxième cas, pourquoi fais-tu tous ses traitements métier coté Silverlight ?
Tu crées simplement une fonction AchatClient(List<Produit> produits, int clientID) ou un truc dans le genre qui prend les produits à acheter et le numéro du client. L'histoire de la carte de fidélité se passe coté serveur.

Bonsoir,

Merci pour ces deux réponses.

Pour ce qui est du cas un, c'est évidemment ce que j'ai fini par faire, une vue qui reprend toutes les infos (du magasin au aspUser) et en un seul appel j'ai toutes les infos.

Pour ce qui est de la question de savoir si ce post à bien sa place dans le forum silverlight, je pense que oui puisqu'il traite essentiellement de callback (et donc de l'asynchrone) qui est pour moi lié à silverlight.

Pour ce qui est des cartes de fidélités, c'est effectivement plus judicieux de traiter ça coté serveur sauf que la seule chose que je suis capable de faire c'est (et c'est justement l'exemple de ma vue UserInfo):

Code:

---

1 2 3 4 5

Public Function GetUserInfoByAspName(ByVal parAspUserName As String) As IQueryable(Of vw_UserInfo) Dim list As IQueryable(Of vw_UserInfo) = From myUserInfo In Me.ObjectContext.vw_UserInfo _ Where myUserInfo.UserName = parAspUserName Return list End Function

---

C'est le genre de fonction que je lance coté client avec un :

Code:

---

1 2	Dim ctx As New J_Context ctx.Load(ctx.GetUserInfoByAspNameQuery(myName), AddressOf callback_GetUserInfoByAspName, Nothing)

---

J'ai donc l'impression qu'il me manque la possibilité de "lancer" une fonction à partir du client qui se déroulerait coté serveur et qui pourrait faire des insert, delete, update....

Auriez-vous un exemple de comment procéder ?

Je pensais que tu parlais de postback d'asp.net en fait :D

Je supposes que tu utilises le framework RIA Services?
Ta fonction GetUserInfoByAspName est normalement décorée d'un attribut Query ( doc ) mais tu peux aussi utiliser d'autre attribut comme Insert (doc) pour une fonction qui insère dans la base ou même Invoke (doc) qui effectue une fonction quelconque côté serveur.

Cela dit, utiliser RIA Services c'est (d'après moi) déporter beaucoup de logique métier côté client puisque c'est essentiellement pour faire du CRUD des entités stockés en base.

Effectivement, j'utilise RIA et je commence à me demander si c'est un bien. Quelles sont les alternatives ?, sachant que la plupart du temps, je fais des applications de gestion ou le CRUD est primordial et ou je dois demander des confirmations à l'utilisateur (du style "Etes-vous sûr de vouloir...")

Bien ou pas bien, ca dépend des préférences. Ca dépend ou tu veux placer ta couche de transport dans l'architecture de ton appli. Voici un schéma d'archi:

Code:

---

1 2	| CLIENT | SERVEUR | Présentation <=> Business <=> Transport <=> Business <=> BDD

---

Selon la place de ta couche transport, la répartition du code business est sur le client ou le serveur.
Avec Ria services, le transport est proche de la bdd donc le business est assez faible, la communication dans la couche transport est assez bas niveau (CRUD + quelques autres fonctions). Ce qui fait que tu auras beaucoup d'allers retours serveur pour faire plein de fonctions quasi élémentaires plutôt qu'une grosse fonction business.
Après tu peux utiliser RIA Services sans faire du CRUD mais en faisant des fonctions plus haut niveau, mais tu perds une partie de l'interêt du framework.

Finalement, c'est une question de goûts, styles, archi!

Merci ;)

Et à ma question de savoir quelles sont les alternatives à Ria ?

Il y'a WCF Data Services dont j'ai entendu parler mais je suppose que ca fait placer la couche de transport au même niveau que RIA Services.
Si tu veux faire beaucoup de business côté serveur le meilleur framework est celui que tes mimines créeront, il y'a tellement de possibilités sur ce qui peut être véhiculé que je doute qu'il existe un framework.