我应该使用会议吗？

Question

I am designing an online time tracking software to be used internally. I am fairly new to c# and .NET though I have extensive PHP experience.

I am using Windows Forms Authentication, and once the user logs in using that, I create a Timesheet object (my own custom class).

As part of this class, I have a constructor that checks the SQL DB for information (recent entries by this user, user preferences, etc.)

Should I be storing this information in a session? And then checking the session object in the constructor first? That seems the obvious approach, but most examples I've looked at don't make much use of sessions. Is there something I don't know that others do (specifically related to .NET sessions of course)?

EDIT: I forgot to mention two things.
1. My SQL DB is on another server (though I believe they are both on the same network, so not much of an issue)
2. There are certain constants that the user will not be able to change (only the admin can modify them) such as project tasks. These are used on every page, but loaded the first time from the DB. Should I be storing these in a session? If not, where else?
The only other way I can think of is a local flat file that updates each time the table of projects is updated, but that seems like a hack solution. Am I trying too hard to minimize calls to the DB?

Answer 1

There is a good overview on ASP.NET Session here: ASP.NET Session State .

If you don't have thousands of clients, but need "some state" stored server-side, this is very easy to use and works well. It can also be stored in the database in multi server scenarios, without changing a line in your code, just by configuration.

My advise would be not to store "big", or full object hierarchies in there, as storing in a session (if the session is shared among servers in a web farm in a database for example) can be somewhat costy. If you plan to have only one server, this is not really a problem, but you have to know that you won't be able to easily move to a multiple server mode easily.

The worst thing to do is follow the guys who just say "session is bad, whooooo!", don't use it, and eventually rewrite your own system. If you need it, use it :-)

Answer 2

I would shy away from session objects. And actually I would say look into .net MVC as well.

The reason I don't use the session is because I feel it can be a crutch for some developers.

I would save all of the information that you would have put into a session into a db. This will allow for better metrics tracking, support for Azure (off topic but worth mentioning) and is cleaner imo.

Answer 3

ASP developers know session state as a great feature, but one that is somewhat limited. These limitations include:

ASP session state exists in the process that hosts ASP; thus the actions that affect the process also affect session state. When the process is recycled or fails, session state is lost. Server farm limitations. As users move from server to server in a Web server farm, their session state does not follow them. ASP session state is machine specific. Each ASP server provides its own session state, and unless the user returns to the same server, the session state is inaccessible.
http://msdn.microsoft.com/en-us/library/ms972429.aspx

Answer 4

Look into the HttpContext.User (IPrincipal) property. this is where user information is stored in the request.

Answer 5

One of the main problems with Session is, that by default, it is stored in memory. If you have many concurrent users that store data in the session this could easily lead to performance problems.

Another thing is that application recycle will empty your in memory session which could lead to errors.

Off course you can move your session to SqlServer or a StateServer but then you will lose on performance.

Answer 6

Most people avoid session state simply because people like to avoid state in general. If you can find an algorithm or process which works all the time regardless of the previous state of an object, that process tends to be more fool proof against future maintenance and more easily testable.

I would say for this particular case, store your values in the database and read them from there any time you need that information. Once you have that working, take a look at the performance of the site. If it's performing fine then leave it alone (as this is the simplest case to program). If performance is an issue, look at using the IIS Cache (instead of session) or implementing a system like CQRS.

Answer 7

Session State Disadvantage

Session-state variables stay in memory until they are either removed or replaced, and therefore can degrade server performance. Session-state variables that contain blocks of information, such as large datasets, can adversely affect Web-server performance as server load increases. Think what will happen if you significant amount of users simultaneously online.

NOTE :- I haven't mentioned the advantages because they are straightforward which are : Simple implementation, Session-specific events, Data persistence, Cookieless support etc.

Answer 8

The core problem with sessions are scaleability. If you have a small application, with a small number of users, that will only ever be on one server, then it may be a good route for you to save small amounts of data - maybe just the user id - to allow quick access to the preferences etc.

If you MAY want multiple web servers, or the application MAY grow, then don't use session. And only use it for small pieces of information.