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

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

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

MSDN не говорит.

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

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

Если ваше приложение зависит от System.Web, оно остановит ваше приложение, чтобы он мог воспользоваться профилем клиента.

Подробнее см. Блог пользователя Scott Gu.

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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