使用 ASP.net Session 的方式可以灵活地从进程内会话存储更改为状态管理服务器或数据库
到目前为止,我的印象是存储会话的位置只是一个配置开关,不需要更改任何代码。我有一个误解,认为从 inproc 迁移到状态管理服务或数据库不需要任何代码更改。
当我意识到存储在会话中的对象需要可序列化(如果它们需要与状态管理服务或数据库一起使用)时,我的误解被打破了。这意味着,我需要将计划放入会话中的所有对象标记为可序列化。
如何使部署人员完全灵活地决定会话存储。我需要注意哪些其他事情(以及序列化)才能使其与任何会话存储选项一起使用。
谢谢。
更新 以下代码应该在 inproc 模式下工作,但我猜,不适用于状态管理或数据库会话存储选项。
UserPreferences 首选项 = Session["UserPreferences"]; //可序列化的用户首选项 首选项.Autologout = true; //我相信,这只适用于inproc。更新后的值不会反映在数据库中。
上述会话处理模式是常见的。如何在编码/编译时而不是在运行时捕获此类问题。是否有静态代码分析规则可用于适当的会话处理。
Until now, I was under impression that where to store your session is just a configuration switch and should not require any code change. I was having misconception that moving from inproc to state management service or database should not require any code change.
My misconception was broken when I realized that the object stored in the session needs to be serializable if they need to work with state management service or database. That means, I need to mark all those objects which I plan to put in session as serializable.
How can I make it completely flexible for the deployers to decide on the session storage. What all other things (along with serialization) I need to take care to make it work with any session storage option.
Thanks.
Update
The following code should work in inproc mode but, I guess, will not work with state management or database session storage option.
UserPreferences preferences = Session["UserPreferences"]; //UserPreferences in serializable
preference.Autologout = true; //I believe, this will only work with inproc. The updated value will not reflect in database.
The above session handling pattern is common. How to catch such issues while coding/compilation and not at run-time. Are there static code analysis rules available for appropriate session handling.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论