Utiliser un modèle synchrone dans Silverlight

Q : J’ai un problème avec le comportement asynchrone dans Silverlight. Toutes mes applications WinForm sont écrites pour le mode synchrone, mon modèle conceptuel (modèle logique) est à base de composants et mon MVP (Model View Presenter) utilise DTO (data transfer object), qui est généré par les

composants associés (modèle logique). Avec l’aide de Windows Communication Foundation (WCF), je pensais qu’il serait très facile de forcer mes composants à se comporter comme un service Web, juste en ajoutant certains attributs. Mais le nouveau modèle de programmation proposé par Silverlight est en mode asynchrone. Existe-t-il un moyen d’utiliser un modèle synchrone dans Silverlight ?

R : Les communications sont synchrones lorsque vous appelez une fonction (une méthode qui retourne une valeur) et que vous obtenez un résultat. Avec des communications asynchrones, vous appelez une sous-routine (une méthode qui ne retourne pas de valeur) et vous passez un délégué callback ou vous effectuez un ancrage sur un événement. Le résultat apparaît dans l’argument de l’événement ou dans les paramètres de la méthode callback. Silverlight vous impose d’utiliser les communications asynchrones pour l’accès à un service. Cela vous évite de bloquer votre application pendant une opération potentiellement longue.

La réponse courte à votre question est « non ». Vous ne pouvez pas utiliser les communications synchrones à partir de Silverlight et vous ne souhaitez probablement pas le faire. Silverlight imite un navigateur et ce type de logiciel est asynchrone. Même si votre application Silverlight sort du cadre du navigateur, elle attend des communications via une connexion du type Internet.

Tandis que les communications côté Silverlight sont asynchrones, une fois que vous arrivez sur le serveur, les autres communications sont généralement synchrones. De nombreux services sont des appels de fonctions et ont un comportement intrinsèque synchrone, même s’ils interagissent avec WCF, lequel répond au client Silverlight de manière asynchrone.

Un pipeline asynchrone peut devenir synchrone, mais l’inverse n’est pas vrai. Tous les pipelines qui retournent une valeur sont au final synchrones, car quelque chose retourne une valeur. Pour préserver l’isolation, chaque étape du pipeline asynchrone communique uniquement avec son voisin et, ainsi, chaque étape du pipeline a sa propre méthode callback ou son événement.

Cette information est pertinente pour votre question, car Silverlight ne force pas des parties significatives de votre application à passer en mode asynchrone. Le code serveur et client non lié aux communications peut rester inchangé. Pour de nombreuses applications, le passage aux communications synchrones constitue un défi, car les mêmes classes effectuent les activités liées aux communications et les autres activités.

La séparation de ces aspects constitue probablement une partie de la solution. Cela vous permet en outre de réutiliser le code sur Silverlight et sur votre serveur en sélectionnant « Add Existing Item », en accédant à l’élément, puis en sélectionnant « Add as Link » dans la liste déroulante du bouton « Add ».