5

I am proposing to use a simple session object in a MVC3 to maintain state data like RecordIds rather than pass them through all the client side pages which will be a hassle. It seems far simpler to just populate the session object the once until no longer in use.

So is this acceptable practice or a cheat??

Many thanks.

SamJolly
  • 6,347
  • 13
  • 59
  • 125
  • 1
    Ive voted to close this as it'll solicit debate as to the pro's and cons. Its not a good fit for QA. That said, there is some similar questions on SO: http://stackoverflow.com/questions/10181629/why-session-is-a-disaster-in-asp-net-mvc-application and http://stackoverflow.com/questions/6165241/asp-net-mvc-session – Jamiec Apr 08 '13 at 11:48
  • I did not fully understand your specific use case (and am also commenting more than six years later ...) but I advise *against* using session for anything that do not *require* their use. The reason is simple: it makes your application statefull while the HTTP protocole was designed to be stateless. This could lead to poor user experience. Sending a link to a specific page to a friend would often result in an improper application state due to the session state not containing the expected date – Mathieu VIALES Oct 28 '19 at 16:12

2 Answers2

9

Like everything in developer's life, using session is a trade-off, and a IMHO it is usually a bad one.

Session state not only causes load on server that tends to grow and creates scalability barrier (both problems can be - partially - solved with storing session variables with state server or sql server), it has a by-design quirk that not everybody is aware of: It maintains a read-write lock on the session. (http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx)

This means that by default, no two concurrent request can be made by the same user. This behavior is asp.net related (not just asp.net MVC), however since asp.net MVC really encourages you to go down the ajax road, you will see this problem much more often).

You can bypass these problems by smartly using readonly session state or selectively disabling it, but from my experience that creates development overhead, since that attribute can only be declared on class scope, and not for specific action methods, which leads you to break apart logical units that would normally lie together.

In conclusion, your honor, asp.net session state default behavior is problematic. Avoid using it if possible.

motime
  • 564
  • 2
  • 10
8

There's nothing wrong with using Session objects. Generally people avoid them to reduce the load on the server; but if you're careful and don't try to put lots of data in there and don't have too many (how many is too many depends on your server) then it is an acceptable practice.

For some info on the potential drawbacks of using sessions check out the answer to Still ok to use Session variables in ASP.NET mvc, or is there a better alternative for some things (like a cart)

Community
  • 1
  • 1
Simon Martin
  • 4,203
  • 7
  • 56
  • 93
  • Thanks, helpful. I always thought it was abit like using a "GoTo" statement in coding. Seems not in the right context. – SamJolly Apr 08 '13 at 11:58
  • Nice example with the cart. I am actually passing data around a workflow, but each workflow step might access another controller to do its job. – SamJolly Apr 08 '13 at 11:59