Modèles de conception de service Web asynchrone

Question

Lors de l'écriture d'une application Silverlight connectée à un service Web WCF, la seule option qui nous est présentée lors de l'utilisation du service Web consiste à effectuer des appels asynchrones à l'interface WS.

-à-dire

WebService client = new WebService(); 
client.ServiceMethodCompleted += new EventHandler<Args>(client_Handler); 
client.ServiceMethodAsync(); 
client.close() 

...followed by 
void client_Handler(object sender, Args e) 
{ 
    //Next step, possibly another method? 
} 

Même si je comprends la raison pour les appels asynchrones lors de l'écriture webapps (filet de sécurité), quel type de modèle de conception pourrait-on utiliser si une méthode a été écrite où chaque étape dépendait du résultat de l'appel du service Web? Par exemple, s'il existait une méthode dans le service Web qui vérifiait les informations d'identification de l'utilisateur du visiteur, et en fonction du groupe de cet utilisateur, effectuerait une action.

public MyPage() //Constructor 
{ 
    CheckCredentialsAsync(); 

    if(result.IsUserTypeA) 
    { 
     //something complex 
    } 
    else if(result.IsUserTypeB) 
    { 
     //something else complex 
    } 
    ...etc 

} 

Est-il possible d'y arriver sans l'aide d'une conception « domino » des méthodes déclenchées par les appels asynchrones précédents événements terminés? Il semble que cela peut devenir désordonné s'il y a beaucoup d'interaction client/service.

Merci!

Answer 1

La meilleure modélisation que je connaisse pour de tels modèles est la machine à états finis pilotée par les événements. Les méthodes asynchrones sont des événements et vos 'opérations complexes' sont des actions, votre instance MyPage est l'état actuel. Cependant FSM peut être assez poilu pour un bon nombre d'états et d'événements, et bien qu'ils puissent être contrôlés en composant des FSM plus simples, je n'appellerais pas ce modèle intuitif et facile par n'importe quel bout. Franchement, je préfère souvent la chaîne de rappel que vous décrivez. L'effet 'domino' n'est pas forcément mauvais, une fois que vous avez écrit quelques modules comme celui-ci, vous avez compris. Sa complexité est essentiellement déterminée par le nombre de branches d'exécution possibles dans les blocs 'quelque chose de complexe'. Où dans le chemin synchrone vous auriez une branche if, dans le chemin asynchrone vous auriez probablement deux rappels séparés. Est plus de code à taper, mais n'est pas nécessairement plus difficile à comprendre. Et la partie 'plus de code' peut être prise en compte avec l'usine appropriée du coe dans helpers. Je pense cependant que je n'ai pas travaillé avec les classes Silverlight, mon expérience concerne principalement le comportement asynchrone des opérations WebRequest, SqlClient et Stream. À la fin, la partie la plus compliquée que je trouve être la division de la gestion des erreurs et la scission de la propriété des ressources, puisque le modèle using est beaucoup moins utile avec async.

Answer 2

Si vous ne voulez pas callbacks chaîne ensemble, consultez le AsyncEnumerator de Jeffrey Richter: http://www.wintellect.com/PowerThreading.aspx

Il prend en charge Silverlight aussi.

Answer 3

JE SUIS D'ACCORD AVEC VOUS:
Regarder une longue chaîne de domino d'appels est laid. Il confond le code car la liste (interminable) d'appels & dans votre page ne communique pas nécessairement aux autres développeurs qu'une série donnée fait partie d'un ensemble unique. C'est pourquoi je voudrais envelopper ces appels dans un seul objet en utilisant un modèle de conception.

Si votre chaîne d'appels domino ...

utilise les données des appels précédents:
J'enveloppait ces appels dans un objet à l'aide DECORATOR daignent modèle. Un bon exemple de quelque chose qui utilise le modèle décorateur est un objet STREAM.

Si votre chaîne domino d'appels ...

NE PAS UTILISER DES DONNÉES PRÉCÉDENT APPELS:
J'enveloppait ces appels dans un objet à l'aide CHAIN OF RESPONSIBILITY daignent modèle.

CEPENDANT
Il y a beaucoup de raisons pour lesquelles vous pouvez utiliser ou ne pas utiliser un ou l'autre-. J'essaie simplement de répondre à votre situation spécifique. Here is how you decide which one to use.