Возможен ли кэш типа T?

Question

Можем ли мы избежать приведения T к Object при помещении его в кэш?

WeakReference требует использования объектов.System.Runtime.Caching.MemoryCache заблокирован для ввода объекта.

Пользовательские словари / коллекции вызывают проблемы с сборщиком мусора, или вам нужно запустить собственный сборщик мусора (отдельный поток)?

возможно ли иметь лучшее из обоих миров?

---

Я знаю, что уже принял ответ, но использование WeakReference теперь возможно!Похоже, они спрятали его в .Net 4.

http://msdn.microsoft.com/en-us/library/gg712911(v=VS.96).aspx

---

старый запрос функции для того же.

http://connect.microsoft.com/VisualStudio/feedback/details/98270/make-a-generic-form-of-weakreference-weakreference-t-where-t-class

Answer 1

Нет ничего, что могло бы помешать вам написать обобщенную оболочку вокруг MemoryCache - возможно, с ограничением, требующим ссылочных типов:

public class Cache<T> where T : class
{
    private readonly MemoryCache cache = new MemoryCache();

    public T this[string key]
    {
        get { return (T) cache[key]; }
        set { cache[key] = value; }
    }

    // etc
}

Очевидно, что стоит делегировать только те части MemoryCache, которые вам действительно интересны.

Answer 2

То есть вы в основном хотите зависеть от внедрения поставщика кеша, который возвращает только определенные типы?Разве это не против всего ООП?

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

Создавая кеш, который кэширует только объекты определенного предопределенного типа, вы ограничиваете функциональность вашего кеша, однако ...

Ничто не мешает вам реализовать пользовательский провайдер кеша, который имеет универсальныйограничение, поэтому он позволяет вам кэшировать только определенные типы объектов, и это теоретически сэкономило бы вам около 2 «тиков» (даже не миллисекунд) за поиск.

Способ посмотреть на это ...

Что для меня важнее:

1. Хороший ООП, основанный на лучших практиках
2. около 20 миллисекунд за время жизни моего провайдера кэша

Другое дело, что ... .net уже настроен на предельную оптимизацию процесса упаковки и распаковки, и в конце дня, когда вы «кешируете» что-то, вы просто помещаете его куда-то, его можно быстро получить и сохранить указательк его местоположению для последующего извлечения.

Я видел решения, которые включают потоковую передачу XML-файлов 4 ГБ через бизнес-процесс.ess, которые используют объекты, которые уничтожаются и воссоздаются при каждом вызове. Дело в том, что процесс важен не только для инициализации и подготовительной работы, если это имеет смысл.

Насколько важна потеря времени приведения кты?Мне было бы интересно узнать больше о сценарии, который требует такой скорости.

В качестве примечания: Еще одна вещь, которую я заметил в более новых технологиях, таких как linq и Entity Framework, заключается в том, что результат запроса важен для кэширования, когда запрос занимает много времени, но не так много.побочные эффекты на результат.

Что это означает, что (например): если бы я должен был кэшировать базовый «экземпляр по умолчанию» объекта, который использует сложный набор запросов сущностей для создания, я бы не кэшировал результирующий объект, нозапросы.

Поскольку Microsoft уже выполняет основную работу, я бы спросил ... что я кеширую и почему?