Asking your opinions on the session object, I never use it (only forced to at work) because of its issues when scaling out the server. I realize you can go out of proc and have sql server manage sessions, but I just don't like that idea of it.
I would rather build a better database design around the issue, than just throw things in session to save database calls.
Am I alone on this one? Should I rethink my stance on sessions?
You are, but only by a little. You're absolutely right -- maintaining session state in the middleware means complications in the app and in the network as the system grows larger.
On the other hand, relatively few applications actually grow so large that multiserver scalability becomes an issue, so depending on the project it might add less complexity.
I'd certainly consider it guilty until proven innocent, though.
I think putting data into Session is useful in some cases, but is also easy to be lazy and abuse it like any other feature. So, I say, use it where appropriate.
What exactly would be the difference between your self-made session handling using the database and the session state stored in a database?
If you need something stateful on the server, using session (with a few small serializable objects in it only of course) seems to be not so bad to me...
I find your stance to be somewhat extreme. Judicious use of the session is definitely ok in my book -- for example, I store some preferences (visibility of filters, etc.) in the session because they are tied to the session rather than persistent across sessions. It can certainly be abused, but it is the abuse, not the use, that I would be against.
There's nothing inherently wrong with using Session state in an ASP.NET web app, as long as you use it sparingly and pay attention to good design principles. For instance, it doesn't make sense to cache large objects in session state and then use SQL Server to manage session state; you will be reading/writing large amounts of data from a database which defeats the objective of caching it in the first place! However, using session state to store some primitives between pages seems OK to me.
You should rethink what you use sessions for rather than completely deciding if to use it or not.
There are many many ways you can store "session" based information from cookies, query strings, as well as the session object.
Session can be overused... a lot... just because people can use it badly though does not make it bad.
Do you want your User object in there? Do you just want a UserId in there?
In my experience it depends entirely on the scenario you are dealing with:
High traffic / Web Farm / Distributed type applications. Session objects are generally a bad thing. You'll have to centralise the information somewhere (shared memory, db, other) and then pay a performance penalty writing/reading to it. That said, without some kind of session state system there is only so much you can acheive with said applications. Using cookies is generally the get-out clause - just watch for sensitive information.
Everything else. Use sessions, they are pretty handy.
"It depends".
I find using _______ (inappropriately) to be an evil practice. Just like I think eating too much ____ is an evil practice.
Everything has its place. Everything can be misused. Knowing when to use what tool, and when to switch is the mark of a master craftsman.
Session is for storing temporary variables, so unless you need to store this data for a large amount of time, i don't see why you would need to design specialized tables in the database just to avoid using session. As for scaling, check out Microsoft Velocity (currently in CTP). I believe session is a good thing. But i follow the principle that even good things, when not used in moderation, can become bad things.
I think you are being too harsh. What some people do with session objects is not always a good idea, but there is nothing inherently wrong with the technology.
Caching is a good use of session objects in the right circumstance. For example, caching user specific data that is stored in the DB and doesn't frequently change except by the actions of that user. This incurs a memory penalty on the web server as a trade-off for fewer hits on the DB server. I am happy to make this trade-off because it is far simpler and cheaper to scale to multiple web servers than multiple SQL servers.
My general rule of thumb is to use sessions only for caching situations. That is, if the code can't easily reload itself after a session expires without intervention from the user, I don't go there.
Probably the best way to use Sessions is to use them to cache session data. In this way you can still keep them InProc in the server farm environment with session affinity so you can get performance benefits. But if you lose the session you can get it again by querying the database.
Session as a mechanism to have global variables of the session scope is evil.
man, here is what i think and i may be wrong
-if you have data that will be shared then use static classes,i have had amazing experince with that, and they are much more efficient.
-use Profile it is Strongly types, but you first have to optimize it or it will kill your site, here is really nice article on that http://msmvps.com/blogs/omar/archive/2006/08/17/optimize-asp-net-2-0-profile-provider-before-you-go-live.aspx.
one more thing is that there is a great trick i have learned from this great guy to purge anonymous profiles.
http://leedumond.com/blog/managing-anonymous-users-for-better-site-performance/
there are many other ways to store user data, this link is really informative http://steveorr.net/articles/PassData.aspx
if you have small site then session is really fine.
hope this helps.
Session is evil in a couple ways. One, it lures you in under the impression that you can easily store any kind of object in it, but when you try to scale it across multiple server's it's like... sorry, you have to make ALL those objects you stored in there serializable. If you don't want to make everything serializable (or can't), then you're stuck with in-proc session state and losing sessions whenever you rebuild your app or recycle the web-app. Finally, there's the overhead to every request it adds when turned on, and the general lack of control you have with any pre-packaged out-of-the-box solution.
You're almost better off going with a custom, highly efficient solution from the beginning. The more I work with it, I realize that Session is a little TOO convenient to be true, in terms of what it seems to offer... but there are legitimate uses.