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

Длительный прослушиватель - первый раз. Я надеюсь получить совет. Я читал о кешировании в .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;
        }
    }
}

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

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

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

Ответ 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>, чтобы пользователи не могли подумать, что они могут добавить в этот список.

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

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

Этот подход позволит вам unit test классы, которые должны делать вещи со всеми категориями, с полным контролем над тестами "категорий" и без необходимости вызова базы данных.

Ответ 2

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

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

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

Все перечисленные функции описаны в ссылке.

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

Ответ 3

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

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

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