Qui a besoin d'enregistrer des données en session

Question

Je crée une petite application avec le framework asp.net mvc. J'ai une question. J'ai construit une structure n-couche (contrôleur -> couche de service -> couche de dépôt) de l'application et créé un wizzard pour recueillir des données de l'utilisateur. Certaines données qui proviennent du référentiel (couche de données) doivent être sauvegardées pour l'étape suivante (par exemple lorsque l'utilisateur appuie sur le bouton de retour sur wizzard), ce ne sont pas des données saisies par l'utilisateur. Pour une raison quelconque, j'ai besoin de mettre ces données en cache dans le dépôt (pour désappliquer lorsque le bouton de retour est enfoncé). Pour mon application je vais enregistrer ces données en session et je ne sais pas qui doit sauvegarder ces données. D'une part, il doit s'agir d'une couche de service - et je dois lui envoyer des sessionstatewrapper. Mais pour la logique métier d'application - pour la couche service j'ai besoin d'envoyer toutes les données de wizzard et de séparer ces données pour certaines étapes il est juste defferent vue pour collecter des données et traiter ces données - c'est un travail de couche de présentation. Des idées d'aide?

P.S. Désolé pour mon anglais =)

Answer 1

Je dirais que c'est quelque chose que le frontend devrait prendre soin de cela. Votre couche de service ne devrait pas avoir à s'inquiéter du fait que ces données sont collectées dans un assistant et qu'il s'agit d'un assistant basé sur le Web, donc votre interface est sans état. Considérez ceci: que l'auriez-vous fait c'était une application basée sur Windows? Votre "frontend" maintiendrait l'état pour vous.

Mais c'est juste mon 0,02 $ ...

Answer 2

Il semble que vous avez une application assez complexe là. Comme vous semblez ne pas être familier avec le framework MVC que vous utilisez, je vous recommande de commencer avec des choses extrêmement simples. Cela signifie que, par exemple, vous ne sauvegardez pas les données jusqu'à la fin. Prévenez vos utilisateurs et, en attendant, apprenez le maximum sur le MVC que vous utilisez. Lorsque vous aurez assez de connaissances, revenez en arrière et ajoutez cette fonctionnalité.

BTW, dans MVC:

• M est le modèle, les données que vous rapportez de fichiers, bases de données, stdin, etc.
• V est la vue, la couche de présentation. Il affiche les données, c'est le frontend.
• C est le contrôleur, il contrôle tout dans l'application. Il récupère les données du modèle, les traite, les envoie à la vue, attend une réponse, obtient la réponse de la vue, la traite, agit en conséquence.

Mes 2 cents sont que vous devriez faire en sorte que le contrôleur prenne soin de l'état de l'assistant.

Answer 3

Est-il nécessaire de l'enregistrer en session ou de l'enregistrer en mémoire sur le serveur?

Dans votre cas, j'aurais utilisé le bloc d'application Enterprise Library Caching. Avec cela, vous pouvez créer un cache de paire clé/valeur où la clé est l'identifiant de l'utilisateur et la valeur est un objet contenant les informations que vous souhaitez stocker. En utilisant EntLib, vous pouvez accéder aux informations de la couche de votre application qui ont le plus de sens et ne pas avoir à vous soucier de l'état de la session.

EDIT

Placez le stockage des données de session dans le modèle. Le modèle est responsable de la gestion des données. La vue montre les données à l'utilisateur et les contrôles du contrôleur.

Answer 4

Si vous transmettez des données dans un assistant, la première chose à laquelle je pense est TempData. C'est précisément l'une de ses utilisations - vous devez conserver quelque chose à la page suivante (ou précédente), à ​​chaque étape. Bien sûr, comme TempData utilise Session, à la fin de la journée, si vous avez besoin d'utiliser Session directement, c'est toujours une option.

C'est le type de chose que le contrôleur doit gérer. Vos couches de service et de référentiel doivent fournir au contrôleur toutes les données dont il a besoin, mais le contrôleur lui-même doit gérer la persistance de ces données dans l'ensemble de votre assistant. Si vous le regardez comme "afficher des données" pour vos pages d'assistant (je ne sais pas si cela est représentatif de vos données ou non, mais cela peut être le cas) cela peut rendre plus clair quel niveau du système devrait être responsable de il.