Зачем использовать статические переменные System.Runtime.Caching или System.Web.Caching Vs?

Question

Долгое время слушатель - впервые звонящий.Я надеюсь получить совет.Я читал о кэшировании в .net - как с помощью System.Web.Caching и System.Runtime.Caching.Мне интересно, какие дополнительные преимущества я могу получить по сравнению с простым созданием статической переменной с блокировкой.Мой текущий (простой) метод кэширования выглядит следующим образом:

public class Cache
{
    private static List<Category> _allCategories;
    private static readonly object _lockObject = new object();

    public static List<Category> AllCategories
    {
        get
        {
            lock (_lockObject)
            {
                if (_allCategories == null)
                {
                    _allCategories = //DB CALL TO POPULATE
                }
            }
            return _allCategories;
        }
    }
}

За исключением срока действия (и я бы не хотел, чтобы срок его действия истек) Я затрудняюсь понять, в чем преимущество использования встроенногокеширование.

Возможно, есть преимущества для более сложных сценариев кеширования, которые мне не подходят - или, может быть, я что-то упускаю (не в первый раз)

Итак, в чем преимущество использования кеша, если я хочу кеш, который никогда не истекает?Разве статические переменные не делают этого?

Answer 1

Прежде всего, Xaqron делает замечание, что то, о чем вы говорите, вероятно, не квалифицируется как кеширование.Это действительно просто глобально доступная переменная с ленивой загрузкой.Это хорошо: как практический программист, нет смысла отклоняться назад для реализации полного кэширования, где это не очень полезно.Однако, если вы собираетесь использовать этот подход, вы также можете быть Lazy и позволить .NET 4 сделать тяжелую работу:

private static Lazy<IEnumerable<Category>> _allCategories
    = new Lazy<IEnumerable<Category>>(() => /* Db call to populate */);

public static IEnumerable<Category> AllCategories 
{ 
    get { return _allCategories.Value; } 
}

Я позволил себе сменить тип на IEnumerable<Category> чтобы вызывающие абоненты не думали, что они могут добавить в этот список.

Тем не менее, каждый раз, когда вы получаете доступ к общедоступному статическому члену, вы упускаете большую гибкость, необходимую для объектно-ориентированного программирования.предлагает.Я лично рекомендую вам:

1. Переименовать класс в CategoryRepository (или что-то подобное),
2. Сделать этот класс реализующим интерфейс ICategoryRepository, с GetAllCategories()метод интерфейса и
3. Интегрируйте этот интерфейс в конструктор любых классов, которые в этом нуждаются.

Этот подход позволит вам использовать классы модульного тестирования, которые должнывыполнять действия со всеми категориями, с полным контролем над тем, какие «категории» тестируются, и без необходимости вызова базы данных.

Answer 2

System.Runtime.Caching и System.Web.Caching имеют автоматическое управление сроком действия , которое может быть в зависимости от изменений файла , Изменения БД SQL Server и вы можете реализовать свой собственный "поставщик изменений"Вы даже можете создавать зависимости между записями кэша.

См. Эту ссылку, чтобы узнать больше о пространстве имен System.Caching:

http://msdn.microsoft.com/en-us/library/system.runtime.caching.aspx

Все функции, которые я упомянулописаны в ссылке.

Использование статических переменных потребует ручного управления истечением срока действия, и вам придется использовать средства наблюдения за файловой системой и другие средства, предоставляемые в пространстве имен кэширования.

Answer 3

Other than expiration (and I wouldn't want this to expire) ...

Если вы не заботитесь о продолжительности жизни, имя больше не caching.

Все еще используете Application (ваш случай) и Session object - лучшие практики для хранения данных уровня приложения и уровня сеанса.