the other day I was discussing with a colleague and he came out saying that using user’s session in a web application is just wrong. I replied that it could be wrong depending by the information you are storing, otherwise why should a web session service even being provided by Microsoft (we were talking about ASP.NET).
He replied to me, again, that even in MS they could easily reply me that it was bad design. And that he could show me some white-papers demonstrating that.
Unfortunately I have no opportunity to contact this guy anymore, but I would really like to understand more about his point of view. Does anyone have information/points of view about that here?
3
I don’t think he meant “Bad design” so much as “Bad practice.” Generally speaking, a web application should be as stateless as conceivably possible. Even though, for example, you may need to know user information in order to authorize page viewing, that information could be saved on the client machine in the form of a cookie and the server simply validates the user information each and every time.
That would be ideal, but you can’t always count on the client being able to save cookies. Furthermore, it involves validating the user in a stateless fashion, which potentially involves querying information from the database for a simple page request. Often times it’s just simpler to save such information in the session.
However, once you’ve crossed the Rubicon, a lot of programmers are tempted to save not only authentication info in the session but many other things as well. This is an anti-pattern and tends to make your web application heavily dependent upon state, which is precisely what was supposed to be avoided in the first place.
Some programmers would hinge on technology like Spring (if you’re using Java) to untangle what would otherwise be a mess of dependencies, but I would argue that that only makes it easier to create dependencies rather than eliminate them. Such technologies should aid your development, not make your anti-pattern less of a problem.
Therefore, a good rule of thumb is that if you can write it stateless, it is probably a better idea to do so or you risk to fall into this trap. Obviously you’re going to run into situations in which this is required, but generally speaking, you should only save information that would otherwise be difficult to reacquire.
2
I think you’re confusing two different topics: 1) sessions and 2) the page model of asp.net webforms
A web session is necessary for authentication a user. Ideally a session should only be used for this purpose. You shouldn’t store user data in a session (whether it be on the server, in a cookie, or as asp.net/webforms does it: within the page itself). No one should say that a web session is bad, but rather, storing user data in a session is a bad practice. The reasons for not storing user data on the server include the same reasons to avoid global variables. Storing user data in cookies or in the page can introduce security issues. Using the page model of asp.net also doesn’t adhere to the stateless nature of the web. You could do a search to find out more about why webforms is a bad design. Sessions on the other hand are a necessary part of web applications.
2
Controls and storing session state on a page are essentially a hack. Is the case of MS – a necessary one as they wanted to be able to provide a development environment where you could design pages as you can in winform environments.
MS have themselves moved towards the MVC architecture (latest version – MVC 4) which is more of a return to what the protocol actually should be – stateless.
There are situations where storing state is still handy but it should be understood that this is the exception rather than the rule.