37

Why is it being said We should not use Session variables in ASP.NET MVC applications ? I came across this answer which says so. In that case how will i maintain the values across requests like Logged in User information and some relevant data associated to his account?

This is Darin's answer.

Why are you using HttpContext.Current in an ASP.NET MVC application? Never use it. That's evil even in classic ASP.NET webforms applications but in ASP.NET MVC it's a disaster that takes all the fun out of this nice web framework.

Community
  • 1
  • 1
Happy
  • 1,767
  • 6
  • 22
  • 26
  • 13
    I didn't say that you should not use Session (actually I said it and I am saying it right now but not in the answer you linked to). I said that you should not use `HttpContext.Current` to access the current HTTP context. – Darin Dimitrov Apr 16 '12 at 21:08
  • Here is an article that explains one reason why using HttpContext.Current is a bad idea - basically it is not thread safe: http://odetocode.com/articles/112.aspx – JTech Sep 15 '16 at 07:54

2 Answers2

28

One of the fundamental principles of frameworks like ASP.NET MVC is that they are stateless, just like the Web is. ASP.NET Web Forms is an attempt to mimic a stateful paradigm over a stateless enviroment. It is a lie, in other words.

Using Session variable in an ASP.NET MVC application is a bit like tying a horn to a horse's head, and calling it a Unicorn.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • 17
    Can you address this portion of the question? `how will i maintain the values across requests` ? Apparently I'm doing this very wrong as well... – asawyer Apr 16 '12 at 21:10
  • 1
    Store them in your database. You should review the tutorials available at http://www.asp.net/mvc, especially the NerdDinner one. – Robert Harvey Apr 16 '12 at 21:11
  • 1
    The backing store in my particular case can sometimes be very very slow, and hitting it each action is just not going to work =/ – asawyer Apr 16 '12 at 21:13
  • @RobertHarvey: But you essentially need a key to get that data from database, how will you maintain that across requests ? – Happy Apr 16 '12 at 21:14
  • @Happy At least I understand that part! It should be part of your Route – asawyer Apr 16 '12 at 21:14
  • 3
    @asawyer: That means if i login to mysite.com with my credentials, i have to send myusername everytime in teh url ? really ? in that case, i can get your information by sending your username. No way ! – Happy Apr 16 '12 at 21:16
  • @happy I misunderstood your question then, sorry! – asawyer Apr 16 '12 at 21:16
  • 4
    @Happy: ASP.NET MVC maintains login state between requests. See http://www.asp.net/mvc/tutorials/older-versions/security/authenticating-users-with-forms-authentication-cs – Robert Harvey Apr 16 '12 at 21:52
  • 20
    I still don't see any reason to not use session state. Sometimes I need to store data across requests, so how I'm going to do that without a session? Sure, I could store them in a database. But what do I gain with that? – Jonathan Egerton Apr 18 '12 at 18:47
  • There are many methods for encryption of your sensitive data, you do not have to use a database. Session state should be avoided, and if you look at all the MVC 1, 2, 3, 4 books, AND the Nerddinner and many best practices MVC applications you will see that sessions are avoided. – Tom Stickel Apr 06 '13 at 00:28
  • what if it's something like merchant data? For instance, you're logged int, swell, asp will maintain that state for you via the auth cookie, but what if there's information that needs to remain on the server like oauth tokens, merchant name and other general profile info that is needed on every request?? – Sinaesthetic Feb 27 '14 at 23:23
  • 7
    There's session, the concept, and `Session` the ASP.NET class. The latter should be avoided as much as possible, but the former is just the layer for state over HTTP. While ASP.NET auth doesn't use `Session`, it very much *does* use sessions. – Chris Pratt May 01 '14 at 19:47
7

You can use session state to persist data, TempData functionality use Session as default to persist the data.

You should minimise the use of session as much as possible, the reason for that is that a lock is taken on session for all request to prevent corruption of the session state, for example multiple Ajax requests will serialise because of this. More information here

You can use alternatives to persist data between request for example you can use the CookieValueProvider, which is part of MVC Futures to bind cookie data to model. You can also persist data in the actual DOM as hidden fields, but again these should be minimised as much as possible as the size of the data will be reflected in network traffic to and from the browser.

I would consider using another data store for your web application if your main store is slow. For example SQLServer CE or an embedded RavenDB.

lawrab
  • 336
  • 2
  • 7
  • They would synchronize not serialize. – KingOfHypocrites Jul 28 '14 at 14:00
  • 1
    Synchronization of parallel requests results in serialization (one after another) – Mark Sowul Aug 31 '15 at 16:12
  • To be clear, serial events are one after another, serialization generally refers to when one takes data in memory and puts it in a format that can be stored to disk. – mikeschuld Jul 26 '16 at 17:18
  • Serialization doesn't mean one after another. I think the word you are looking for is "sequential" where multiple processes happen one after the other. Serialize is when an object is turned into raw bytes for something like "sending them over a stream" or "tcp/ip socket connection", or storing them on disk, etc etc. I think the proper word in the conext here is Sequentialization where a parallel algorithm or process turns into a series of sequential processes. – Ryan Mann Feb 27 '17 at 22:40