Использование «кэшированных» сущностей LINQ

Question

У меня проблема в том, что я реализовал WCF-сервис, который использует сущности LINQ ... Чтобы сгенерировать содержимое ответа на вызов сервиса, требуется большое количество LINQ / SQL-выборок ...

Как бы то ни было, служба не выполняет никаких обновлений или вставок в БД, поэтому я хотел бы реализовать своего рода «кеширование» сущностей LINQ (также контент БД не растет миллионами ... он действительно будет ограничен примерно 63 000 основных (с подзависимостями), таких как Пользователь -> Заказы)

Кроме того, ответ службы не должен содержать данные с обновлением 100% up2date, поэтому обновления данных в фоновом режиме не должны быть предметом обдумывания.

Хорошо, сейчас мой план выглядит следующим образом:

• Получите ВСЕ соответствующие таблицы из базы данных с помощью LINQ, чтобы все объекты были "кэшированы" (функция ToList () должна это делать, верно?)
• Заменить объект-сущность с помощью умных потоков каждые x-минуты / часы (например, снова получить данные из базы данных, заблокировать текущий кэшированный linq-DataContent и заменить его новым ..)

Итак, каково ваше мнение ... как вы думаете, я должен / мог бы сделать это так? Мне действительно нужно увеличить время отклика службы, но оптимизация SQL (например, меньшее количество вариантов выбора) не является для меня возможным вариантом, так как все функции LINQ уже реализованы.

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

Answer 1

Для меня это звучит как преждевременная оптимизация. Рассмотрим:

1. Есть много вещей, которые могут замедлить работу приложения, подобного этому. Запросы к БД могут вообще не быть медленной. Если медленной частью является L2E-компиляция, результаты кэширования - это неправильное решение.
2. Правильное выполнение аннулирования кэша обычно сложнее, чем оптимизация запросов. Есть, конечно, исключения.
3. EF уже кэширует экземпляры сущностей в контексте. Убедитесь, что вы не изобретаете велосипед.

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

Answer 2

Я думаю, что предложенный вами подход уместен. В любом случае, если вы не уверены, что к всем регистрам базы данных в соответствующих классах всегда обращаются, я бы изменил его так, чтобы вместо извлечения целых таблиц при запуске он получал регистры в первый раз, когда они необходимы. Примерно так:

GetRegister(id)
    if cache has not register with that id
        retrieve register from database
        store register in cache
    return cached register

Таким образом, ваш кеш реализован, но вы не тратите впустую память.