кэширование данных общего поиска - стратегии

Question

Рассматривая реализацию кэширования для некоторых общих поисковых данных в веб-приложении asp.net.

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

Я немного изучил System.Web.Caching, но, похоже, он не дает никаких преимуществ по сравнению с одноэлементным подходом. Мы не используем SQLServer, поэтому мы не сможем воспользоваться SQLCacheDependency в тех редких случаях, когда данные могут измениться.

Кто-нибудь имеет опыт использования любой из этих альтернатив? Или есть лучшее предложение?

Answer 1

Одним из преимуществ System.Web.Caching является то, что память хранится в пуле приложений. Это удобно, потому что очень просто установить ограничения памяти / обработки для пулов приложений.

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

Я не знаю, зависят ли данные в вашем кеше от нагрузки, но если это так, это полезное преимущество.

Answer 2

Я не могу говорить о преимуществах System.Web.Caching, поскольку, как и вы, я обычно реализую единичные экземпляры структуры данных таблицы поиска. Класс singleton также предоставляет метод InvalidateCache () для обработки редких случаев, когда данные могут измениться.

Если вы создаете библиотеку бизнес-объектов для использования как в asp.net, так и, например, в winforms, то вы можете отказаться от использования System.Web.Caching.

Платформа Business Object, которую я использую, предоставляет базовый класс для таблиц поиска, называемый NameValueListBase . Этот базовый класс предоставляет строго типизированные вспомогательные методы. Вы можете разработать аналогичный базовый класс и предоставить свои собственные вспомогательные методы, в отличие от простого предоставления экземпляра System.Collections.Generic.Dictionary.

Каркас бизнес-объекта, на который я ссылаюсь, называется CSLA.Net и подробно объясняется в Expert C # 2008 Business Objects . Существует также версия книги, доступная для VB.Net.

Answer 3

У меня есть опыт работы с обоими. Я предпочитаю шаблон синглтона по следующим причинам:

1. Это не связано с asp.net
2. Позволяет использовать поиск в слое bisiness для проверки или чего-либо другого.
3. Рефакторинг проще, если поиск становится более сложным, и вы решили не кэшировать его.