Considérations pour le threading dans l'environnement Web

Question

Je commence le développement Web ASP.NET et je me demandais quelles sont les différences lorsque multi-threading une application winforms standard par rapport à une application Web écrite dans asp.net qui fonctionnera dans IIS . Y at-il une différence et si oui, quelles sont les limitations (et inversement les points positifs) de threading une application Web, Merci d'avance

Answer 1

Dans le monde Windows GUI, vous avez toujours le "thread UI" que vous pouvez utiliser pour communiquer avec l'utilisateur. Par exemple, vous pouvez démarrer un BackgroundWorker dans le thread UI, ce qui déclenchera un événement dans le thread UI après avoir terminé son travail: Dans une application Windows UI, vous pouvez être sûr que le thread UI est toujours là, sauf si l'utilisateur a fermé l'application.

Dans le monde Web, vous n'avez aucun équivalent thread principal. Il y a juste des requêtes web: parfois il n'y en a pas et parfois il y en a plusieurs en même temps; Il est même possible qu'une seule requête soit traitée par plusieurs threads sans que vous le sachiez. Si vous commencez un fil d'arrière-plan avec une opération longue, vous devez soit

• retard finition de la demande Web jusqu'à ce que le fil de fond a terminé - ce qui signifie un temps de réponse lent pour l'utilisateur et des défaites en quelque sorte l'objet d'une thread d'arrière-plan ou
• régulièrement (lors de futures demandes) vérifier l'état du thread et informer l'utilisateur quand il a terminé.

Bien sûr, c'est seulement un problème si vous voulez une interaction de l'utilisateur une fois le thread terminé. Si ce n'est pas le cas, lancez-le et il finira par se terminer (à moins que quelqu'un ne redémarre IIS).

Answer 2

Threading n'est pas vraiment un problème dans le monde du Web. Il n'y a pas d'état et chaque requête est une nouvelle instance de la page Web. Il existe des moyens de suivre l'état entre les demandes telles que cookies, sessionstate, viewstate.