Est-ce une bonne pratique d’éviter l’utilisation de l’état de session dans ASP.NET MVC? Si oui, pourquoi et comment?

Dans les formulaires Web ASP.NET, la transmission d’informations entre différentes pages n’a jamais été particulièrement simple sans l’utilisation de la session. En raison du modèle centré sur le postback, les informations étaient disponibles sur le serveur dans le cadre d’un événement, mais souvent dans une page incorrecte pour l’affichage d’un résultat, rendant nécessaire la transmission d’informations entre les pages.

Cela avait tendance à conduire à une surutilisation de la session, remplissant les variables “en cours” dans la session pour indiquer quel était l’object en cours d’interaction. Cette surutilisation a à son tour rendu les applications très dépendantes de l’état et beaucoup plus difficiles à déterminer le comportement attendu (“Cette variable est-elle remplie?”

MVC est structuré autour de l’idée que votre site Web est une vue dans un modèle logique d’informations. Il encourage les opérations sans état à l’aide de contrôleurs simples répondant à des actions avec des informations clés transmises dans le cadre de la requête HTTP.

En raison de ces propriétés, la session n’est plus nécessaire pour effectuer des tâches de base dans MVC, et devient de moins en moins adaptée lorsque le choix semblait parfaitement valable auparavant.

Fondamentalement, la session pollue HTTP . Cela rend les requêtes (contenant souvent leur propre état) dépendant de l’état interne du serveur de réception. C’est pourquoi il est considéré comme un mal (bien que souvent pratique et nécessaire).

La session a été évitée même avant MVC, car les informations persistantes sur le serveur pour chacun des utilisateurs qui se connectent à votre application et (contrairement au cache) ne sont pas automatiquement effacées lorsqu’elles ne sont pas utilisées.

De plus, afin de vous aider à éviter d’utiliser la session, ASP.NET disposait de viewstate, qui était en fait un énorme champ caché dans vos formulaires Web qui était affiché à chaque publication. Cela aussi était trop maladroit pour diverses raisons et a été abandonné avec MVC.

Donc, la session est quelque chose qui n’était pas très recommandé, même avant MVC. La raison en est principalement l’évolutivité. Moins vous persistez, plus votre site sera évolutif. Si vous ne vous souciez pas de l’évolutivité (pour ce que je sais que vous développez peut-être une application intranet pour 200 utilisateurs) ou si vous avez très peu d’informations à conserver, utilisez la session. Dans d’autres cas, l’utilisation de session est tout à fait appropriée: un scénario typique où l’état de session est utilisé est le panier d’achat sur un site de commerce électronique (informations insortingnsèquement par utilisateur et par pourcentage).

En ce qui concerne les alternatives, il n’y a pas de remplacement direct pour la session. Selon ce que vous essayez de faire, vous pourrez peut-être utiliser le cache ou les cookies. MVC n’a rien apporté de particulièrement nouveau à cet égard, AFAIK.

Qu’est-ce que cela signifierait d’éviter d’utiliser l’état de session pour vous? Avez-vous besoin de stocker facilement de petites quantités de données utilisateur dans les requêtes? Si oui, comment le feriez-vous autrement?

Je ne suis pas sûr de ce que seraient vos alternatives à l’état de la session. En utilisant l’état de la session tel qu’il existe, ASP.NET est bien plus souhaitable pour déployer votre propre alternative, en particulier du sharepoint vue de la sécurité.

Utilisez TempData au lieu de HttpSessionState . TempData est le wrapper Mvc de l’état Session.

Ajout aux réponses précédentes

Les sessions sont généralement mauvaises en termes d’applications modernes et les applications modernes s’appliquent principalement aux applications centrées sur le cloud, mais dépendent énormément de l’endroit où nous les stockons.

Indépendamment de ASP.NET WebForms ou ASP.NET MVC, généralement avec session, nous imaginons un panier avec panier rempli ou supprimé, qui est maintenu tout au long de la maintenance de la session. C’était donc une façon simple et peu coûteuse de faire les choses.

1. InProc
2. StateServer
3. Serveur SQL
4. Maintenant sur le cache dissortingbué plus de détails

HTTP par naissance est sans état, de sorte que lorsque nous souhaitons augmenter horizontalement l’application, nous ajoutons des nœuds à un niveau Web ou à d’autres niveaux. Le problème est désormais de savoir quel nœud répondra à la demande de l’utilisateur actuel. cela dépend énormément de l’équilibreur de charge qui a différents modes d’équilibrage.

Ainsi, plusieurs nœuds peuvent servir des requêtes pour un même utilisateur en fonction de loadbalancer, mais nous pouvons remplacer par une session sticky au niveau Web qui garantira que l’utilisateur actuel utilisera les mêmes nœuds, échoue lors de la montée en charge. sur chaque nœud 2 et maintenant nous ajoutons un nœud supplémentaire, nous nous attendons généralement à ce que 3 nœuds partagent un nombre de sessions égal, mais cela échoue car ces 1 000 doivent être actifs dans des nœuds particuliers. effacé.

Encore une fois, que faire si nous voulons augmenter ou inverser l’application de l’échelle? ou un ou plusieurs serveurs tombent en panne, des données de session entières seront perdues si nous conservons la session sur InProc ou StateServer et même si les noeuds de niveau Web changent pour le même utilisateur, semble être un cache dissortingbué rapide et fiable.

Cela dépend vraiment de la quantité de données que vous conservez dans l’état de la session. En règle générale, j’essaie de l’utiliser pour quelques cordes ici et là et pas beaucoup plus. Par exemple, pour un formulaire volumineux, je peux stocker un ID de référence dans cette session, puis stocker toutes les données nécessaires dans les tables temporaires SQL basées sur cet ID. C’est un peu pénible, mais l’état de la session n’est pas destiné à stocker des quantités d’informations.

L’expiration de la session ne correspond généralement pas à l’intention de l’utilisateur (par exemple, si IIS est recyclé, votre état de session inproc est perdu). La seule chose à laquelle je pense être utile est la mise en cache des données utilisateur, et non la source de vérité faisant autorité (qui devrait très probablement être la DB).

La gestion de session a toujours été un défi de ASP.net Web Forms à ASP.net MVC. Cependant, MVC encourage à le traiter comme étant sans état, car vous bénéficiez de l’API Web basée sur REST . La plupart des choses que nous avions l’habitude de stocker dans Session ont déjà été réalisées en utilisant les deux combinaisons d’API Web MVC +.