我可以将会话状态存储在 ASP.NET MVC 应用程序的现有 SQL Azure 数据库中吗?
我使用代码优先风格的 EF4.1 在 SQL Azure DB“MyAppsDB”中为基于 ASP.NET MVC 3 的小型 Web 应用程序保留 POCO 对象。当表不存在时,系统会在 MyAppsDB 中自动创建这些表。我想在 SQL Azure 上托管该应用程序,但我不想每月支付 10 美元购买额外的 1GB 数据库来存储 50MB 的会话状态,而且使用缓存会更加昂贵。
我想将会话状态与我的应用程序模型一起存储在 MyAppDB 中。有办法做到这一点吗? 如果会话表不存在,是否可以自动创建它,与 EF 代码优先模型相同?
我尝试按如下方式修改我的 web.config:
<sessionState mode="Custom" customProvider="DefaultSessionProvider">
<providers>
<add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
connectionStringName="MyAppDBContext" applicationName="/" />
</providers>
</sessionState>
但它抱怨会话表不存在。如果我创建会话表,EF4.1 会抱怨数据库元数据不符合其预期。
I'm using EF4.1 in code-first style to persist POCO objects for a small ASP.NET MVC 3-based webapp in an SQL Azure DB 'MyAppsDB'. The tables are automatically created in MyAppsDB when they don't exist. I'd like to host the app on SQL Azure, but I don't want to pay $10/mo for an extra 1GB DB to store 50MB of session state, and using Cache would be even more expensive.
I'd like to store session state in MyAppDB along with my app's models. Is there a way to do this?
Can I have the Session table auto-created if it doesn't exist, same as EF code-first models?
I've tried modifying my web.config as follows:
<sessionState mode="Custom" customProvider="DefaultSessionProvider">
<providers>
<add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
connectionStringName="MyAppDBContext" applicationName="/" />
</providers>
</sessionState>
But it complains the session table doesn't exist. If I create the session table, EF4.1 complains that the DB metadata doesn't match its expectations.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当然可以使用现有的 SQL Azure 数据库作为会话状态。我正在这样做(并且出于完全相同的原因)。标准脚本不起作用,因为它们与 SQL Azure 不兼容。有一些更新的脚本(我不记得在哪里,但我有一个谷歌)我用来设置数据库。
但它不是代码优先。您也许能够对模式进行逆向工程,但是涉及到许多存储过程。
请注意,您还需要考虑清理过期的会话。有一个存储过程需要定期运行(我认为DeleteExpiredSessions),典型的建议是从辅助角色运行它。但是您不会希望部署辅助角色的唯一目的是定期运行存储过程!
编辑:在 上找到脚本此页面。请注意,主文章中发布的脚本存在问题,但 Peter McEvoy 的评论中在页面下方有一个修改过的脚本。
有些人建议优先使用 Azure 表存储会话状态提供程序,如果我还没有使用 SQL Azure,我会倾向于同意。但是我在使用 Azure 提供程序时遇到了问题(特别是在开发环境中),但在部署更新的脚本后使用 SQL Server 会话状态完全没有问题。
编辑 2:我已经取得了进一步的进展,我会将其写在我的博客中并在此处发布链接。
但重点是:
我想就这些了,但是当我写完它时,我会在我的博客上给出更完整的描述。
编辑3:
我的文章的第一部分现在是在我的博客上。第二部分即将推出(但现在该睡觉了)。
编辑4:
第二部分现在也已编写。
It's certainly possible to use your existing SQL Azure database for session state. I'm doing exactly that (and for exactly the same reason). The standard scripts don't work, as they're not compatible with SQL Azure. There are some updated scripts somewhere (I can't remember where, but I'll have a Google around) that I used to set up the DB.
It's not code-first, though. You may be able to reverse-engineer the schema, but there are a number of stored procs involved.
Note that you'll also want to think about tidying up expired sessions. There's a stored procedure that needs running periodically (DeleteExpiredSessions, I think) and the typical recommendation is to run it from a Worker Role. But you won't want to deploy a Worker Role for the sole purpose of running a stored procedure periodically!
Edit: Found the script on this page. Note that there's an issue with the script posted in the main article, but there's a modified script further down the page in a comment from Peter McEvoy.
Some recommend use of an Azure Table Storage session state provider in preference and if I wasn't using SQL Azure already, I'd be inclined to agree. But I've had problems with the Azure provider (particular in the dev environment) but have had no problems at all using SQL Server Session State once the updated scripts are deployed.
Edit 2: I've made further progress and I'll write it up for my blog and post a link here.
Highlights, though are:
I think that's about it, but I'll give a more complete description on my blog when I've written it up.
Edit 3:
Part I of my write-up is now on my blog. Part II coming soon (but time for bed, now).
Edit 4:
Part II is also written, now.