我可以将会话状态存储在 ASP.NET MVC 应用程序的现有 SQL Azure 数据库中吗?

发布于 2024-11-29 01:46:52 字数 789 浏览 0 评论 0原文

我使用代码优先风格的 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

ぶ宁プ宁ぶ 2024-12-06 01:46:52

当然可以使用现有的 SQL Azure 数据库作为会话状态。我正在这样做(并且出于完全相同的原因)。标准脚本不起作用,因为它们与 SQL Azure 不兼容。有一些更新的脚本(我不记得在哪里,但我有一个谷歌)我用来设置数据库。

但它不是代码优先。您也许能够对模式进行逆向工程,但是涉及到许多存储过程。

请注意,您还需要考虑清理过期的会话。有一个存储过程需要定期运行(我认为DeleteExpiredSessions),典型的建议是从辅助角色运行它。但是您不会希望部署辅助角色的唯一目的是定期运行存储过程!

编辑:在 上找到脚本此页面。请注意,主文章中发布的脚本存在问题,但 Peter McEvoy 的评论中在页面下方有一个修改过的脚本。

有些人建议优先使用 Azure 表存储会话状态提供程序,如果我还没有使用 SQL Azure,我会倾向于同意。但是我在使用 Azure 提供程序时遇到了问题(特别是在开发环境中),但在部署更新的脚本后使用 SQL Server 会话状态完全没有问题。

编辑 2:我已经取得了进一步的进展,我会将其写在我的博客中并在此处发布链接。

但重点是:

  • 针对空数据库运行 InstallSqlState.SQL 脚本(针对 Azure 的修改脚本)
  • 使用 EF Power Tools 将 ASP 状态表逆向工程到 EF Code-First
  • 将逆向工程类集成到模型和上下文中
  • 修改 ASPStateTempSessions 表的映射以使用 Image 列类型
  • 从 InstallSqlState.SQL 创建一个新的 SQL 脚本,该脚本仅创建存储过程
  • 修改存储过程以始终指定默认值
  • 添加一些代码在 Initializer Seed() 方法中运行 SQL 脚本

我想就这些了,但是当我写完它时,我会在我的博客上给出更完整的描述。

编辑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:

  • Run the InstallSqlState.SQL script (the modified one for Azure) against an empty database
  • Use EF Power Tools to reverse-engineer the ASP State Tables into EF Code-First
  • Integrate the reverse-engineered classes into your model and context
  • Modify the mapping for the ASPStateTempSessions table to use an Image column type
  • Create a new SQL Script from InstallSqlState.SQL that just creates the stored procs
  • Modify the stored procs to always specify default values
  • Add some code to run the SQL Script in the Initializer Seed() method

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文