Pergunta

Eu sei que há uma pergunta muito semelhante aqui Mas eu esperava obter uma explicação melhor. Por que eu usaria httpcontext.cache em vez de httpruntime.cache se o httpcontext realmente usar o httpruntime.cache nos bastidores?

No artigo Simule um serviço Windows usando asp.net para executar trabalhos agendados Omar usa o HttpContext para armazenar seus itens de cache, mas quando Jeff Atwood o implementou aqui Ele escolheu usar o httpruntime. Obviamente, nessa situação específica, faz sentido, já que você não precisa fazer uma solicitação da Web para adicionar o item de cache ao httpcontext.

No entanto, estou procurando algumas boas dicas sobre quando usar uma contra a outra.

Foi útil?

Solução

É realmente o mesmo cache no final, apenas HttpContext.Current Às vezes, pode ser nulo (quando não está em um contexto da web ou em um contexto da web, mas ainda não é construído). Você estaria seguro para sempre usar HttpRuntime.Cache.

Outras dicas

Quando você está em uma página da web regular, você pode usar com segurança HttpContext.Cache ou apenas o Cache propriedade da página.

Se você está fazendo algo que não está em uma página, geralmente precisa usar HttpRuntime.Cache Para obter acesso com segurança.

Em alguns casos, você pode saber se existe um contexto HTTP ou não, por exemplo, se você iniciar um thread separado de uma página da Web, esse thread não possui contexto HTTP. Em outros casos, você pode ter um contexto HTTP às vezes, como no Application_Start método em global.asax, como o aplicativo nem sempre pode ser iniciado porque há uma solicitação.

Acho isso enganador também, embora todos saibamos que apenas retorne HttpRuntime.Cache internamente. Além disso, o HTTPRUNTIME é uma má escolha para expor o cache, eu acho.

Todo mundo SAIS como Session é o cache no nível da sessão e o cache de que estamos falando é no nível do aplicativo. Eu preferiria ter Application.Cache Como o cache que estamos usando hoje e HttpContext.Cache para se referir ao que é conhecido como HttpContext.Items.

Quanto a responder à sua pergunta, acho que todos devemos manter o httpruntime.cache, tornando nosso código mais claro, mesmo que tenhamos várias maneiras de acessá -lo. E quando você planeja seriamente usá -lo, é melhor embrulhar sua própria API e ligar internamente HttpRuntime's ou qualquer outra implementação de cache (Entlib, velocidade, etc ...).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top