我正在设计一个内部使用的在线时间跟踪软件。尽管我有丰富的PHP经验，但我对c＃和.NET相当陌生。我应该使用会话吗？
我使用Windows窗体身份验证，而一旦使用用户登录，我创建了一个时间表对象（我自己的自定义类）。
由于这个类的一部分，我有一个构造函数，检查SQL数据库信息（该用户，用户偏好最近条目等）
我应该存储在会话信息？然后在构造函数中首先检查会话对象？这看起来很明显，但我看过的大多数例子都没有充分利用会话。有什么我不知道其他人做的（特别是与.NET会话有关）？
编辑： 我忘了提两件事。
1.我的SQL数据库在另一台服务器上（尽管我相信它们都在同一个网络中，所以问题不大）
2.有一些常数，用户将无法更改（只有管理员可以修改它们），比如项目任务。这些用于每个页面，但是第一次从DB加载。我应该将这些存储在会话中吗？如果没有，还有哪些地方？
我能想到的唯一的另一种方式是每次更新项目表时更新的本地平面文件，但这似乎是一种破解解决方案。我是否努力尽量减少对数据库的调用？
这里有一个很好的关于ASP.NET Session的概述：ASP.NET Session State。
如果您没有成千上万的客户端，但需要“某些州”存储的服务器端，这是非常容易使用和运作良好。它也可以存储在多服务器场景的数据库中，而不需要通过配置改变代码中的行。
我的建议不是将“大”或全部对象层次结构存储在那里，作为存储在会话中（例如，如果会话在数据库中的Web场中的服务器之间共享）可能会有些费钱。如果您打算只有一台服务器，这并不是一个真正的问题，但您必须知道，您将无法轻松地轻松转移到多服务器模式。
最糟糕的事情是跟随那些只说“会话不好，whooooo！”的人，不要使用它，并最终重写自己的系统。如果你需要它，使用它:-)
窥视HttpContext.User（的IPrincipal）属性。这是用户信息存储在请求中的地方。
Session的一个主要问题是，默认情况下，它存储在内存中。如果有很多并发用户在会话中存储数据，这很容易导致性能问题。
另一件事是应用程序回收将清空您的内存会话，这可能会导致错误。
当然，你可以移动会话的SqlServer或StateServer的，但那么你将失去的性能。
大多数人避免会话状态只是因为人们喜欢避免一般状态。如果你可以找到一个始终工作的算法或过程，而不管对象以前的状态如何，那么这个过程往往会更加适合未来的维护，并且更易于测试。
我会说这个特定的情况下，存储你的价值观在数据库中，并从那里阅读它们，你需要这些信息的任何时间。一旦你有这个工作，看看网站的性能。如果它表现良好，请保持独立（因为这是编程最简单的情况）。如果性能问题，请查看使用IIS缓存（而不是会话）或实施像CQRS这样的系统。
我会回避会话对象。实际上，我会说看看.net MVC。
我不使用会话的原因是因为我觉得它可以为一些开发商拐杖。
我会将所有会放到会话中的信息保存到数据库中。这将允许更好的度量跟踪，支持Azure（脱离主题但值得一提），并且更加清晰。
ASP开发人员知道会话状态是一个很棒的功能，但有一点是有限的。这些限制包括：
ASP会话状态存在于承载ASP的进程中;因此影响进程的动作也会影响会话状态。当进程被回收或失败时，会话状态丢失。 服务器场限制。当用户在Web服务器场中从服务器到服务器移动时，其会话状态不会跟随它们。 ASP会话状态是特定于计算机的。每个ASP服务器都提供自己的会话状态，除非用户返回到同一台服务器，否则会话状态将不可访问。
http://msdn.microsoft.com/en-us/library/ms972429.aspx
这是从http://msdn.microsoft.com/en-us/library/ms972429.aspx – 2011-12-28 15:05:31
@Simon复制粘贴无修改，所以我给一个链接。 – 2011-12-28 15:38:08
会话状态缺点
会话状态变量保存在内存中，直到它们被取出或更换，因此会降低服务器的性能。包含大量数据集等信息块的会话状态变量会随着服务器负载的增加而对Web服务器性能产生负面影响。想想如果你有大量的用户同时上网会发生什么。
注： - ：与会话可扩展性简单实现，会话特定的事件，数据持久，无Cookie支持等
的核心问题我没有，因为他们是直接的，其是提到的优点。如果您的应用程序规模较小，只有少量用户，而且这些应用程序只能在一台服务器上运行，那么为您保存少量数据（可能只是用户标识）可能是一条很好的途径，可以快速访问首选项等。
如果您可能需要多个Web服务器，或者应用程序可能增长，请不要使用会话。只能用于小块信息。
你不应该注意。 HTTP是无状态的。 – 2011-12-28 13:57:38