Можно ли использовать HttpRuntime.Cache вне приложений ASP.NET?

Question

Скотт Хансельман говорит да .

Добавление System.Web в ваш не веб-проект - хороший способ заставить людей паниковать. Еще один добавляет ссылку на Microsoft.VisualBasic в приложении C #. И то, и другое разумно и чертовски полезно.

MSDN говорит нет .

Класс Cache не предназначен для использования вне приложений ASP.NET. Он был разработан и протестирован для использования в ASP.NET для обеспечения кэширования веб-приложений. В других типах приложений, таких как консольные приложения или приложения Windows Forms, кэширование ASP.NET может работать неправильно.

Так что я должен думать?

Answer 1

Я понимаю, что этот вопрос старый, но в интересах помочь любому, кто найдет его с помощью поиска, стоит отметить, что .net v4 включает новый кэш общего назначения для этого типа сценария. Он находится в пространстве имен System.Runtime.Caching:

https://msdn.microsoft.com/en-us/library/dd997357(v=vs.110).aspx

Статическая ссылка на экземпляр кэша по умолчанию: MemoryCache.Default

Answer 2

Не должно быть никаких проблем с использованием HttpRuntime.Cache. Это сложная хэш-таблица в памяти, которая может быть очень полезна вне веб-контекста. Тем не менее, может быть немного неприятно пахнуть кодом для ссылки на HttpRuntime.Cache в приложении, не относящемся к Http, поэтому может быть хорошей идеей заключить его в некоторый интерфейс ICache и использовать его везде, где это возможно.

Answer 3

Следует помнить, что Microsoft выпустила пакет установки профиля клиента .NET Framework. Это версия платформы 3.5, которая предназначена для клиентских приложений и имеет уменьшенную площадь. Профиль клиента не включает части платформы ASP.NET.

Если ваше приложение зависит от System.Web, оно не позволит вашему приложению использовать преимущества профиля клиента.

См. Блог Скотта Гу для более подробной информации.

Answer 4

В текущих версиях System.Web.Caching.Cache, похоже, нет ничего, что зависело бы от времени выполнения HTTP, за исключением метода Insert(), который принимает CacheItemUpdateCallback, поэтому Скотт подходит по большей части.

Это не мешает Microsoft изменить класс в будущем для большей интеграции с инфраструктурой HTTP.

В другом ответе я написал облегченный кэш на основе WeakReference .

Answer 5

Если вы ищете общее решение: это типичная ситуация для подхода внедрения зависимостей. Используя этот подход, вы можете следовать за Скоттом Хансельманом и MSDN!

Добавление зависимости System.Web, такой как HttpRuntime.Cache, без ссылки System.Web в вашей библиотеке.

Answer 6

Я однажды использовал его, но он не чувствовался правильным, и IIRC значительно увеличил объем памяти. Вместо этого я реализовал свой собственный легкий механизм кэширования, который на удивление легко сделать.

Он использовал класс WeakReference , который позволял кешу сохранять ссылки на объект, но также позволяет сборщику мусора восстанавливать память, если ссылка не используется.

Единственное, чего у меня не было, - это отдельного потока для очистки устаревших элементов в кэше. Что я сделал, так это если бы в кеше было> х элементов, я бы прошел все кэшированные элементы и удалил старые элементы перед добавлением нового.

Если вам нужно что-то более надежное, используйте что-то вроде MS Enterprise Library Кэширующий блок приложения .

Answer 7

Не используйте его, даже если он работает, он может перестать работать в следующем пакете обновлений / версии.

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

Answer 8

Почему бы не полностью избежать вопроса и использовать Блок кэширования библиотеки предприятия ? Вы можете использовать System.Web.Caching, но вы, вероятно, не получите поддержку Microsoft, если столкнетесь с проблемами и поднимете брови, так что это может не стоить этого.