我过去曾听过建议在项目早期使用 SqlServer / StateServer，因此当您进行扩展时，您不会陷入使用不可序列化对象 InProc 的开发人员的陷阱，并且在迁移到 SqlServer / 时它会中断StateServer 稍后。
目前我们不需要使用 SqlServer 会话状态的 InProc，因为我们刚刚启动，但我们可能需要合理地快速扩展。
在使用 InProc 时，是否有人对强制可序列化对象有任何建议？也许创建一个包装器？
【问题讨论】：
标签： asp.net session-state serializable inproc session-state-server
要记住的重要一点是，使用 SqlServer/StateServer 不仅仅是横向扩展（网络农场）。即使在一台服务器上，您也可能在仅使用 InProc 会话时遇到问题。基本上，在使用 InProc 时，应用程序池回收时“实时”的任何会话都会丢失。将这一点放在上下文中，您可能正在运行购买渠道并在会话中存储对流程至关重要的内容（为什么这可能是不好的做法是另一个对话）。无论如何，如果该会话信息损坏/丢失，则用户将无法继续。因此，应用程序池会回收并丢失所有当前活动的会话 - 因此当前在您的购买渠道中的所有客户都会退出并可能会丢失。
仅出于这个原因，我总是建议至少运行 SqlServer 会话（甚至在本地）。更好的架构通常可以消除任何性能问题。如果您确实遇到性能问题，您可能会查看我应该更快的第 3 方 StateServer 实现。
如果在阅读了在实时服务器上运行 InProc 的缺点之后，您仍然很乐意这样做（这是您的原因，所以没关系）我唯一可以建议的就是更改您的开发服务器（或测试) 使用 SqlState 运行并让 Live 运行 InProc。这样您就可以在不使用 InProc 的环境中看到任何问题，并且可以在非实时环境中修复它们。然后，如果您决定切换 Live，您就会知道它不需要任何额外的开发工作，一切都会好起来的。
【讨论】：