在没有会话状态的情况下构建 ASP.NET 应用程序？
我刚刚看完 Stefan Schackow 的 PDC 2009 会议，他提到他对人们仍在使用 Session 感到惊讶ASP.NET 中的状态。会话状态甚至在 ASP.NET 中内部使用MVC。
在使用旧应用程序时，所有内容都放入“进程内”会话（甚至数据表！），我亲眼目睹了会话滥用。
有没有办法在没有会话状态的情况下构建 ASP.NET 应用程序？您将如何存储典型电子商务工作流程每个步骤的信息？
I just finished watching Stefan Schackow's PDC 2009 session and he mentioned that he is surprised that people are still using Session State in ASP.NET. Session State is even used internally in ASP.NET MVC.
Having worked with a legacy application where everything is put into a "in-proc" session (even datatables!), I've seen session abuse first-hand.
Is there a way to build an ASP.NET application without session state? How would you store information for each step of a typical e-commerce workflow?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用以下选项：cookie、数据库、查询字符串、页面变量和服务器缓存来尝试处理 Web 的无状态性质。每个都有自己的权衡，但实际上，我目前使用存储在数据库中的会话。这对于服务器场来说可以很好地扩展，有助于保持较小的页面大小，并且易于实现。
You've got the following options: cookies, database, querystring, page variables, and server cache to try to handle the stateless nature of the web. Each has its own tradeoff, but pragmatically speaking I currently use session that gets stored in the db. This scales well for server farms, helps to keep your pagesize small, and is easy to implement.
我已经很多年没有使用会话了。如果您需要跟踪用户在页面之间的进度（例如，通过购物车结帐流程），请将您需要的任何状态信息存储在数据库中，并使用 cookie 将其与用户关联起来。
值得注意的是，.NET 支持不同的“会话”机制，其中一种机制将信息存储在数据库中（我认为这是首选）而不是进程内。
I haven't used a session in years. If you need to track a user's progress between pages (say, through a cart checkout process), store whatever state information you require in a database and relate it back to the user with a cookie.
It's worth noting that .NET supports different "session" mechanisms, one of which stores the information in a database (much preferred in my opinion) instead of in-proc.
查看 ASP.NET 会员资料。它允许您序列化和存储/检索每个用户帐户的对象，无论用户是否匿名。我已经能够在冗长的向导式在线应用程序中成功地使用它。
Check out ASP.NET Membership Profiles. It allows you to serialize and store/retrieve objects per user account, regardless of whether the user is anonymous or not. I've been able to use this successfully with lengthy wizard-type online applications.