На мой взгляд, лучшее решение будет иметь следующие характеристики:
Использует доступные службы кэширования, предоставляемые платформой, стараясь не писать свои собственные.
Не связывает вашу библиотеку классов с System.Web, чтобы обеспечить согласованность слоев.
Но если библиотека классов работает внутри приложения ASP.NET, решение не должно требовать включения другой реализации кэширования (например, блока приложения кэширования Enterprise Library), которая требует дополнительной настройки и настройки.
Итак, я бы использовал стратегию IoC, чтобы позволить библиотеке классов использовать различные реализации кэширования в зависимости от среды, в которой она работает.
Предположим, вы определили свой абстрактный кеширующий контракт как:
public interface ICacheService
{
AddItem(...);
}
Вы можете предоставить реализацию на основе System.Web:
public AspNetBasedCacheService : ICacheService
{
AddItem(...)
{
// Implementation that uses the HttpContext.Cache object
}
}
И затем эта реализация «публикуется» как синглтон. Обратите внимание, что отличие от вашего первоначального подхода в том, что синглтон - это просто ссылка на реализацию, основанную на службе кэширования ASP.NET, а не полный «объект кэша».
public class ChacheServiceProvider
{
public static IChacheService Instance {get; set;}
}
Вы должны были бы инициализировать реализацию chaching либо путем выполнения отложенной инициализации, либо при запуске приложения (в global.asax.cs)
И каждый компонент домена сможет использовать опубликованную службу кэширования, не зная, что она реализована на основе System.Web.
// inside your class library:
IChacheService chache = CacheServiceProvider.Instance;
cache.AddItem(...);
Я согласен, что это, вероятно, не самое простое решение, но я стремлюсь воспользоваться преимуществами реализации кэша ASP.NET без ущерба для развязки кода и гибкости.
Надеюсь, я правильно понял ваш вопрос.