.Net: Кэширование на уровне данных с несколькими интерфейсами

Question

У меня есть проект бизнес-объектов и слой данных, который потенциально может быть реализован в нескольких интерфейсах (веб-сайт, веб-службы, консольное приложение и т. Д.).

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

Если библиотека используется для веб-проекта, я хотел бы использовать HttpRuntime.Cache; однако, я предполагаю, что это будет проблемой для консольных приложений.

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

Answer 1

Если вы используете .net 4.0, вам следует заглянуть в MemoryCache в пространстве имен System.Runtime.Caching . Это было добавлено в .net 4.0 специально для устранения того факта, что приложения, не являющиеся ASP.NET, не имели API-интерфейса для кэширования или должны были поставляться с зависимостью от System.Web и использовать HttpRuntime.Cache. В качестве альтернативы вы можете изучить кэширование AppFabric, которое не зависит от клиента, но может повлечь за собой дополнительные затраты, с которыми вам не нужно иметь дело.

Если вы работаете с более ранней версией .net, вы можете найти самый простой способ - откусить пулю и получить зависимость от System.Web, тогда вы можете использовать HttpRuntime.Cache везде - это не идеальное решение, но оно обладает последовательностью. В качестве альтернативы можно взглянуть на блок кэширования корпоративной библиотеки , который опять-таки не зависит от клиента, но не рекомендуется для использования в веб-приложениях, где доступен материал HttpRuntime.

Answer 2

Добавить кеширующий слой.

Либо вы реализуете кэширование в каждой отдельной реализации уровня данных, либо вы можете сэкономить много работы и просто внедрить кэширование в отдельном слое над уровнем данных, так что вам придется сделать это только один раз. Это дает дополнительное преимущество, заключающееся в том, что вы будете кэшировать свои объекты передачи данных, в то время как если вы поместите кэширование в th DL, вы, возможно, допустили ошибку кэширования необработанных данных, что означает, что вы будете переводить их в DTO каждый раз, когда вы будете работать кеш.

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

Итак:

[различные реализации DL] - [интерфейс DL] - [уровень кэширования] - [интерфейс DL] - [верхние уровни]

Answer 3

Обычно то, что я видел в прошлом, было бы промежуточным уровнем между уровнями данных / представления, которые реализуют кеширование для конкретного хранилища кеша.

В этой статье на сайте asp.net представлен небольшой обзор архитектуры, которую я видел в прошлом.

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