Кеширование в asp.net-mvc
Я хотел бы кэшировать свои самые тяжелые действия с базой данных на моем сайте asp.net-mvc. В своем исследовании я обнаружил
- кеширование пончиков в блоге Фила
- Фильтры Кеширование / сжатие в блоге Кази
- Подкаст Скотта Ханслемана о том, как они кэшируют вещи в SO.
Но я еще не понял, что понял. Я хочу иметь возможность кэшировать свой запрос POST в зависимости от нескольких частей. Эти части находятся в объекте. Поэтому я хотел бы кешировать результат следующего запроса:
public ActionResult AdvancedSearch(SearchBag searchBag)
Где searchBag - это объект, содержащий (набор) необязательных параметров поиска. Сами по себе мои представления невелики (как и должно быть), но доступ к данным может занять довольно много времени, в зависимости от того, какие поля заполнены в сумке поиска.
У меня такое чувство, что я должен кэшировать свой уровень данных, а не свои действия. Как мне использовать VaryByParam в атрибуте OutputCache?
нет, не видел. Постараюсь, что вы скажете. А как насчет перечисления нескольких параметров?
VaryByParam = "firstParam; secondParam; thirdParam"
Немного поздно, но блок приложения кэширования корпоративной библиотеки включен в .Net 4.0, поэтому теперь вы можете использовать MemoryCache System.Runtime.Caching для аналогичного эффекта. Тоже где угодно :)
Ответы 4
Я также люблю кэшировать в модели или на уровне данных. Это изолирует все, что связано с извлечением данных из контроллера / презентации. Вы можете получить доступ к кешу ASP.NET из System.Web.HttpContext.Current.Cache или использовать блок кэширования приложения из корпоративной библиотеки. Создайте свой ключ для кэшированных данных из параметров запроса. Не забудьте сделать кеш недействительным при обновлении данных.
Думаю, мне стоит почитать об Enterprise Library. Поскольку большая часть задержки происходит на уровне данных, я думаю, что в конечном итоге это будет лучшим решением. В настоящее время это БД, доступная только для чтения, поэтому проблема устаревшего объекта решается :)
Блок приложения для кеширования кажется излишним. Я обнаружил, что почти в каждом случае HttpRuntime.Cache более чем адекватен.
Зачем переборщить? Сейчас я намного дальше в разработке, и я обнаружил, что система кеширования EL действительно проста в использовании. Ссылка на правильную библиотеку, добавление правильных строк конфигурации, и вы можете начать кэширование и получение объектов с одной строкой кода для каждого.
Я думаю, что некоторых людей раздражает шаг «добавить правильные строки конфигурации».
Было бы хорошо, если бы вы также могли объяснить, как сделать недействительным кеш памяти, когда в базе данных есть обновления, часто ли вы используете службу для проверки, а затем как очистить кеш?
Или вы можете быть независимыми от HttpContext.Current и получить доступ к кешу из HttpRuntime.Cache :)
Это также означает, что вы по-прежнему сможете получить доступ к «кешу», когда код выполняется в фоновом потоке (то есть, async / await goodness).
Часто OutputCaching может быть самым быстрым и эффективным, но только тогда, когда он соответствует вашим требованиям. Нет смысла иметь быстро и эффективно, если это неправильно! ;)
В этом случае кажется, что кэширование на уровне данных является правильным, потому что у вас сложные потребности в кэшировании. Иногда их можно комбинировать, если набор параметров, управляющих кэшируемым выводом, прост.
вы можете использовать кеширование вывода что-то вроде этого
[OutputCache(Duration = 10, VaryByParam = "empID")]
public ActionResult GetEmployeeDetail(int empID)
{
Employee e = new Employee();
return Content(e.getEmployeeDetails(empID));
}
или вы можете использовать профили кеша, установите его в веб-конфигурации
<caching>
<outputCacheSettings>
<outputCacheProfiles>
<add name = "Admin"
duration = "86420" varyByParam = "none"/>
</outputCacheProfiles>
</outputCacheSettings>
</caching>
and use this tag
[OutputCache(CacheProfile = "Admin")]
Вы пробовали использовать VaryByParam = "searchBag.property"?