Persistance des données utilisateur dans MVC 3

J'ai reçu l'obligation de conserver les données utilisateur une fois que l'utilisateur s'est authentifié initialement. Nous ne souhaitons pas accéder à la base de données pour rechercher l'utilisateur chaque fois qu'il accède à une nouvelle vue, etc ...Persistance des données utilisateur dans MVC 3

J'ai une classe User qui est [sérialisable] donc elle peut être stockée dans une session. J'utilise aussi SQL Server pour l'état de la session. Je pensais stocker l'objet en session mais je déteste vraiment faire ça.

Comment les développeurs sont-ils en train de gérer ce type de besoin ces jours-ci?

Source

2011-12-16 Code Jammr

Quelles données voulez-vous conserver? Voulez-vous dire suivre les activités des utilisateurs? Utilisez-vous l'authentification par formulaire de gain par défaut? –

J'ai une petite classe d'utilisateurs, avec quelques accessoires dedans. userId, nom d'utilisateur, lastjournin date etc. –

non, je n'utilise pas le formulaire par défaut authenticationauthentication ou le fournisseur d'appartenance. Pas que cela importe vraiment trop dans ce contexte si –

Trois façons:

Crypter des données dans les cookies et l'envoyer au client, décryptant chaque fois que vous en avez besoin
Le stocker côté serveur par un identifiant (par exemple UserId) en cache, session, ou tout autre stockage (qui est plus sûr que cookie).
Utiliser deuxième stratégie de mise en cache de niveau si vous avez utilisé un ORM

Source

2011-12-16 19:52:31

J'utilise EF 4 pour mon ORM Je vais regarder dans l'option 3 je suppose. –

Jetez un oeil à http://www.infoq.com/news/2011/09/second-level-caching-ef –

WOW, c'est une énorme charge de code pour quelque chose de simple. Il ne semble pas que ça va bien jouer avec la façon dont je reçois mon DbContext –

En supposant que votre objet utilisateur est pas énorme et je pense ne change pas souvent il est acceptable de le stocker dans la session. Comme vous avez déjà une session SQL Server, vous allez faire des appels SP pour tirer/pousser les données déjà et ajouter un petit objet à cela devrait avoir des problèmes de perf minimal par rapport à d'autres options comme persister jusqu'au client et le renvoyer à chaque demande. Je considérerais également le serveur un endroit beaucoup plus sûr pour garder cette information.
Vous voulez réduire le nombre de fois que vous écrivez à la session (demander un verrou) quand il est stocké dans sql car il est implémenté dans une classe scellée que l'exclusivité verrouille la session. Si l'une de vos autres demandes dans cette session requiert un accès en écriture à la session SQL, elles seront bloquées par la demande initiale jusqu'à ce qu'elle libère le verrou de session. (Il y a quelques nouveaux hooks dans .NET 4 pour vous permettre de changer le SessionStateBehavior dans le pipeline avant que la session soit accédée)

Vous pourriez envisager un serveur d'état de session (appfabric) si perf de votre magasin de session SQL est un problème .

Source

2011-12-16 20:03:03 felickz

Persistance des données utilisateur dans MVC 3

Répondre

Questions connexes