A implementação de cache corretamente em uma biblioteca de classe para uso em um aplicativo asp.net

Question

Estou implementando um cache em uma biblioteca de classe que eu estou usando em um aplicativo asp.net.

Eu criei o meu objeto de cache como um padrão singleton com um método estático para atualizar o cache que é realmente apenas o carregamento de uma variável de membro / propriedade com uma coleção de dados que eu preciso em cache (tem algum é claro lógica de bloqueio). Achei que era uma boa maneira de ir desde que eu só posso acessar meus dados chamando

MyCacheObject.Instance.MyDataCollection

Estou criando um novo objeto de cache para armazenar um bem grande quantidade de dados particionado pela chave. O que estou dizendo é que eu estou criando um novo cache, mas este não irá carregar todos os dados de uma só vez, mas sim armazenar uma coleção para cada tecla acessado.

MyOtherCacheObject.Instance.MyOtherDataCollection(indexkey)

Desta vez, a pergunta sobre a coleta de lixo foi criado. Desde que eu sou armazenar uma enorme quantidade de dados, não seria um desperdício se ele tem gc'ed de repente? Uma vez que é apenas um padrão Singleton não há nada garantindo que os dados ficarão em cache.

Então, minha pergunta é - o que é melhor prática para implemeting um cache para lidar com esta situação? Eu realmente não como um enorme solução complexa para isso, e eu sei que é o cache em System.Web mas que parece um pouco 'off' uma vez que esta é apenas uma biblioteca de classes, ou o que você acha?

Answer 1

Na minha opinião, a melhor solução seria ter as seguintes características:

• Usa os serviços de cache disponíveis fornecidos pela plataforma tentando evitar escrever o seu próprio.

• não par a sua biblioteca de classe para System.Web, a fim de ter as camadas coerente.

• Mas, se a biblioteca de classes está sendo executado dentro de uma aplicação ASP.NET a solução não deve exigir para trazer outra implementação de cache em (por exemplo, o Enterprise Library Caching Application Block), que exige configuração e instalação adicional.

Então, eu usaria uma estratégia IoC, a fim de permitir que a biblioteca de classes a usar diferentes implementações de cache, com base no ambiente que está sendo executado.

Suponha que você definir o seu contrato caching abstrato como:

public interface ICacheService 
{
    AddItem(...);
}

Você poderia fornecer uma implementação baseada em System.Web:

public AspNetBasedCacheService : ICacheService
{
    AddItem(...)
    {
        // Implementation that uses the HttpContext.Cache object
    }
 }

E, em seguida, tem que a implementação 'publicado' como Singleton. Note que a diferença com a sua abordagem original é que o Singleton é apenas uma referência para a implementação baseada serviço de cache ASP.NET, em vez de o 'objeto de cache' completo.

public class ChacheServiceProvider 
{
    public static IChacheService Instance {get; set;}

}

Você teria que inicializar a implementação chaching quer através da realização de inicialização lenta, ou na inicialização do aplicativo (em global.asax.cs)

E cada componente de domínio seria capaz de usar o serviço de cache publicada sem saber que ele é implementado com base em System.Web.

// inside your class library:
IChacheService chache = CacheServiceProvider.Instance;
cache.AddItem(...);

Eu concordo que ele provavelmente não é a solução mais simples, mas eu estou querendo aproveitando a implementação de cache ASP.NET sem sacrificar a dissociação código e flexibilidade.

Espero que eu entendi sua pergunta direita.

Answer 2

Os dados que não se lixo coletado, enquanto o cache ainda mantém uma referência a ele.

Além disso, não nunca usar Singletons.