在请求之间保持/缓存数据 - 常用方法

Question

我正在开发一个Asp.net(MVC,但这并不重要)应用程序.我有一个自定义IHttpModule负责PostAuthenticateRequest更改用户主体和身份.

我在用户登录时将UserID和UserName存储在身份验证cookie中.我有一个IUser(由DAO和Business Objects层实现,每个都有自己的额外成员),我需要遍布业务服务类.当用户想要任何东西时,我必须提供IUser对象实例(通常来自Business Objects层),因此从auth票证中提供ID是不够的.

所以我在考虑如何以及在哪里最好坚持登录用户的IUser数据？

1. 我不想每次从数据库中获取它(基于身份验证票据的UserID数据)
2. 我不能将它存储在Session中,因为我必须在PostAuthenticateRequest中工作,其中Session还没有准备好
3. 我希望所有功能都封装在我的自定义IHttpModule中

我看到的选择:

• 高速缓存
• 曲奇饼
• (会话) - 从PostAuthenticateRequest移动到PostAcquireRequestState事件并在那里更改主体/身份,但我想避免这个

似乎使事情复杂化的过程是:

1. 用户登录时,将从数据库中提取用户数据,并以某种方式保留以供以后的请求使用
2. 用户注销,必须自动从持久介质中删除用户数据
3. 用户更改自己的配置文件,必须丢弃用户数据并在DB的下一个请求中重新读取

我不希望所有这些都由HttpModule自动处理(如果可能的话),以消除开发人员忘记重置这些事情的错误.

我也不想要的是写/读一些硬编码变量/键并在应用程序的其他部分操作它们.这只会出现技术债务.

问题

1. 你会建议什么？
2. SO如何在请求之间保留用户数据？

Answer 1

根据您的要求，我认为最好的解决方案是从 cookie 中检索 ID 并使用它来索引 Http 缓存 (HttpContext.Current.Cache)。

如果您想维护用户访问它的方式，请将缓存包装在“UserCache”对象中。该对象可以由 HttpModule 构建，并作为（等待它...）单例存储在缓存本身中，或者更好的是，在需要从 http 缓存中提取时构建。这取决于您需要在哪里访问它以及 HttpContext.Current.Cache 是否直接可用。惰性实现如下。

再次强调，这是为了清楚起见，并不是我实际实现它的方式。

public class UserCache
{
  public IUser GetUser(object userKey)
  {
    return HttpContext.Current.Cache[userKey];
  }

  public void AddUser(object userKey, IUser user)
  {
    /* this could pull the key from the user object as well. */
    HttpContext.Current.Cache.Add(/* add the object with key and a sliding expiration that is slightly greater than session timeout */);
  }

  public void ExpireUser(object userKey)
  {
    HttpContext.Current.Cache.Remove(userKey);
  }

  /* If you don't want to do SQL cache dependency */
  public void UpdateUser(object userKey, IUser user)
  {
    HttpContext.Current.Cache.Insert(/* ... */);
  }
}

使用默认的缓存机制（或者更好的是 DI 提供的缓存机制，这样您就不必依赖于实现），您可以设置过期时间以自动从缓存中删除用户，如评论中所述。您可以将缓存设置为依赖于 SQL Server 更新来处理更新，或者将其作为服务的一部分手动更新以保存更改。

有关默认缓存的更多信息可在此处获得。有关缓存依赖性的更多信息可在此处获得。

在 HttpModule 本身中，我想您可以在 EndRequest 事件中做一些魔术来查看请求是否经过身份验证，然后根据 cookie 将用户注销，但我不确定这是否有效，因为我从未尝试过它。您可能想在 1.1 时代之前查看MSDN 上的这篇文章，看看它是否回答了您想要解决的一些问题。

至于SO架构以及他们如何做到这一点，我想他们会在需要时加载它，因为他们始终将大部分数据库保存在RAM中（http://highscalability.com/stack-overflow-architecture）。