Should I use ASP.NET sessions or avoid them and why?

Question

Should I use ASP.NET sessions or avoid them and why?

Answer 1

For intranet applications, i use them (but not much, really).

For external applications, use them if you want but only if you've got a single server.

For big apps with heaps of users, and multiple web servers behind a proxy balancer, you probably should start thinking of how to build your site to avoid using them. The best option i personally would use is storing encrypted data in the users cookie.

Answer 2

I try to avoid sessions, but not to the point that it's detrimental to the application. Let's face it, some designs are better with sessions than trying to circumvent them. In general though, I don't use them for stuff I can easily store elsewhere.

Answer 3

ASP.NET Session State FAQ this will answer the positive aspects of what having session vaiables, etc... have.. I try to avoid them for some things and others I use them for..so a answer to a question like this varies

Answer 4

ASP.NET's session management is good so don't make a rod for your own back by trying to avoid using it. ASP.NET's session management capabilities scale up quite well to provide a number of different solutions depending on your needs. You should also keep an eye on Microsoft's Velocity project.

Kev

Answer 5

Use them if you must. In small uses its a easy enough way to transfer data between pages , but never stick controls into the session especially between pages , you are just going to open yourself to a world of hurt.

Answer 6

I use session variables often, but not for big sized objects. Problem with the session variables is that you can forget to clear them when you finish your work, you you can hardcode it's key everywhere in your code. for these reasons I encapsulate session variables in a object that I call sessionvariables. and access them over it. when I need to clear them I define a method in my object to clear all variables over session.

Instead of viewstate or querystring it fits best for most cases that I faced.

Answer 7

For new applications, I try to avoid them and just prefer an encrypted or signed cookie. This is admittedly just a new-found personal preference: Just because it's one more thing to break, and after working to keep a site up 24/7/365 for two years, it's the only thing that has broken in a head-scratching, mysterious way. It's also easy to forget to add [Serializable] on your objects and watch them blow up at runtime when they try to get stored in an out-of-proc session. So it's another gear to grind, so to speak.

That said, I've been using sessions for years without any significant issues other than just having to worry about keeping the session store up and running all the time. If you're InProc, you have to worry about sessions getting zapped every time the app pool restarts, and it can cause the worker process memory usage to balloon, which is another downside; with one of the other methods, it's nice to be able to release a point update to the Web site and not affect any customer's current states.

(I personally haven't seen problems with scaling out sessions, even on multiple servers. But then again I work for a small business [about 3 page views/second]. I figure you're usually talking to the database anyway for something, the cost of fetching the session is in that wash.)

So using sessions isn't a bad choice, you just have to remember not to get carried away with it. Think of it as a server-side cookie, trying to limit yourself to an artificial 4KB or so barrier. For existing applications I certainly don't bother un-sessionizing them, but in general I now prefer to keep it simple and try to do without.

Answer 8

I use them quite often for small objects but over time I've eventually built a simple layer that sits on top of the session, it handles things like clearing the session and casting to the right type, managing the keys. This also stops clashes happening.

There are somethings that I cannot store in the query string and somethings I do not want stored in the view state. All that's really left is the session.