Persistindo / cache de dados entre solicitações - abordagem comum

Question

Estou desenvolvendo um Asp.net (MVC, mas isso realmente não importa) aplicação. Eu tenho um costume IHttpModule que é responsável pela PostAuthenticateRequest à mudança principal usuário e identidade.

Eu estou armazenando UserID e UserName no cookie de autenticação quando usuário efetua-in. Eu tenho um IUser (implementado pelo DAO e Business Objects camada, cada um com seus próprios membros adicionais) que eu preciso todo classes de serviço de negócios. Quando um usuário quer o que eu tenho para oferecer instância do objeto IUser (geralmente a partir de Business Objects camada) para fornecimento de ID do ticket auth não é suficiente.

Então, eu estou pensando em como e onde seria melhor para persistir logado dados IUSER do usuário?

1. Eu não quero pegá-lo cada vez que a partir do DB (com base em dados UserID do tíquete de autenticação)
2. Não posso armazená-lo em sessão desde que eu tenho que trabalhar no interior PostAuthenticateRequest, onde Session ainda não está pronto
3. Eu quero toda a funcionalidade a ser encapsulado dentro do meu costume IHttpModule

As escolhas que eu vejo:

• Cache
• Cookie
• (Session) - ao passar de PostAuthenticateRequest para PostAcquireRequestState evento e principal mudança / identidade lá, mas eu gostaria de evitar isso

Processos que parecem coisas complicar são:

1. registros-in do usuário, dados do usuário é obtido a partir da DB e persistiu alguma forma para pedidos posteriores
2. toras-out do utilizador, de dados do utilizador tem de ser removido a partir do meio persistente automágicamente
3. Usuário muda próprio perfil, os dados de utilizador para ser descartado e reler na próxima solicitação do DB

I wan't todas essas para serem tratadas automaticamente por HttpModule (se possível) para eliminar erros do desenvolvedor de esquecer de repor essas coisas.

O que eu também não quero é escrever / ler algumas variáveis ??/ chaves hardcoded e manipulá-los em outras partes da aplicação. Este seria apenas presente dívida técnica.

Perguntas

1. O que você sugere?
2. Como o SO persistir dados do usuário entre solicitações?

Answer 1

Dada suas necessidades, eu suponho que a melhor solução é para recuperar o ID do cookie e usá-lo para o índice no cache Http (HttpContext.Current.Cache).

Se você quiser manter a forma como os usuários acessá-lo, enrole o cache em um objeto "UserCache". O objeto pode ser construído por um HttpModule e armazenado como um (espera para ela ...) singleton dentro do próprio cache ou, ainda melhor, apenas construído quando precisava puxar a partir do http cache. Isso vai depender de onde você precisar acessá-lo e se HttpContext.Current.Cache está diretamente disponível. A implementação preguiçoso está abaixo.

Novamente, isso é para maior clareza e não é como eu realmente implementá-lo.

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(/* ... */);
  }
}

Usando os mecanismos de cache padrão (ou melhor ainda um mecanismo de cache fornecido pelo DI então você não está amarrado a uma implementação), você pode definir uma expiração para remover automaticamente os usuários do cache como mencionado no comentário. Você pode configurar o cache para ser dependente de atualizações do servidor SQL, assim como para lidar com as atualizações ou atualizar manualmente-lo como parte do serviço para salvar as alterações.

Mais informações sobre o cache padrão está disponível aqui . Mais informações sobre de cache dependências está disponível < a href = "http://msdn.microsoft.com/en-us/library/system.web.caching.cachedependency.aspx" rel = "nofollow noreferrer"> aqui .

No HttpModule em si, eu suponho que você poderia fazer alguma magia no evento EndRequest para ver se o pedido é autenticado e, em seguida, registrar o usuário para fora com base no cookie, mas eu não tenho certeza se isso iria funcionar como eu' ve nunca tentou. Você pode querer ter um olhar para este artigo no MSDN do caminho de volta nos 1,1 dias e ver se ele responde a alguns dos problemas que você está tentando resolver.

Como para a arquitetura SO e como eles fazem isso, eu imagino que eles carregá-lo quando necessário porque eles mantêm a maior parte do banco de dados na RAM em todos os momentos ( http://highscalability.com/stack-overflow-architecture ).