Entity Framework Plus - возможно ли разделять сущности между разными запросами?

Question

Я оцениваю EntityFramework Plus для EF6. NET framework 4.7.2 (не Core).

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

Мой вопрос заключается в том, являются ли объекты в кеш поделился каким-то образом?

Например, если мой первый EF-запрос был:

var employees = myContext.LookupData.Where(x=>x.Id < 100).FromCache()

И мой второй EF-запрос был выполнен, скажем, через 10 минут после того, как первый myContext был Dispose () d , было:

var employees = myContext.LookupData.Where(x=>x.Id < 50).FromCache()

Мы можем видеть, что набор результатов для второго запроса будет содержать записи из первого запроса.

Будет ли Entity Framework Plus проверять, существует ли сущность EF, которая собирается материализоваться в памяти, уже существует в кеше из первого запроса или в некотором кеше общих сущностей?

Если нет, что является ли наилучшей практикой кэширование неизменяемых или редко изменяемых сущностей с EF Plus для совместного использования между запросами?

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

Заранее спасибо.

Answer 1

Используется кеш MemoryCache: https://github.com/zzzprojects/EntityFramework-Plus/blob/master/src/shared/Z.EF.Plus.QueryCache.Shared/QueryCacheManager.cs#L41

Будет ли Entity Framework Plus проверять, существует ли сущность, которую EF собирается реализовать в памяти, уже существует в кеш

Объекты из обоих запросов будут разными. Даже если они имеют одинаковый идентификатор, ссылка не будет одинаковой. Причина в том, что в первом запросе вы могли включить связанные отделы, но не во второй. Таким образом, мы вообще не проверяем, находятся ли объекты в кеше или нет.

Что является лучшим способом кэшировать неизменяемые или редко изменяемые

Зависит от того, что если у вас всего 2000 сотрудников, то, вероятно, загрузите все один раз и повторно используйте кэш-память. Фильтрация на стороне приложения небольшого списка не снижает производительность:

var employees = myContext.LookupData.FromCache().Where(x=>x.Id < 100);