强制实施InProc的可序列化会话状态访问？

Question

我过去曾听过过在项目中早期使用SqlServer / StateServer的建议，因此在扩展时，不要陷入使用非可序列化对象InProc的开发人员的陷阱，并且在迁移到SqlServer时它会破坏/ StateServer稍后。

目前我们没有必要使用InProc的SqlServer会话状态，因为我们刚刚启动，但我们可能需要快速合理扩展。

在使用InProc时，是否有人在强制执行可序列化对象方面有任何建议？也许创建一个包装器？

Answer 1

重要的是要记住，使用SqlServer / StateServer不仅仅是扩展（Web场）。即使在一台服务器上，只需使用InProc会话就会遇到问题。基本上，当使用InProc时，任何在应用程序池回收丢失时“活动”的会话。要将其置于上下文中，您可能正在运行购买渠道并在会话中存储对流程至关重要的内容（为什么这可能是不好的做法是另一个对话）。无论如何，如果该会话信息损坏/丢失，则用户将无法继续。因此，应用程序池会回收并丢失任何当前正在进行的会话 - 因此当前在您的购买渠道中的任何客户都会退出并可能会丢失。

仅仅因为这个原因，我总是建议至少运行SqlServer会话（甚至在本地）。更好的架构通常会抵消任何性能问题。如果您遇到性能问题，您可能会看到我应该更快的第三方StateServer实现。

如果在阅读了在实时服务器上运行InProc的缺点后，你仍然很乐意这样做（他们是你的理由，这样很好）我唯一能推荐的就是改变你的开发服务器（或测试）使用SqlState运行并让Live运行InProc。这样你就可以看到环境中没有使用InProc的任何问题，并且可以在非实时环境中修复它们。然后，如果您决定切换Live，您将知道它不需要任何额外的开发工作，一切都应该没问题。