Где бы вы реализовали кэширование в. NET Core web / api приложении? - PullRequest
Новая
       71

Где бы вы реализовали кэширование в. NET Core web / api приложении?

0 голосов
/ 23 марта 2020

У меня есть следующая архитектура:

  • . NET Веб-приложение Core 3.0 с использованием бритвенных страниц для пользовательского интерфейса
  • . NET Приложение Core 3.0 web api, обслуживающее все данные в веб-приложение. Он общается с базой данных через Entity Framework

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

Что я обсуждаю, на каком уровне реализовать уровень кэширования? Давайте использовать пример приложения, отображающего список ваших предстоящих встреч.

Вариант 1 -> Сделайте это в веб-приложении. Я мог бы реализовать фабрику или подобный шаблон, где веб-приложение больше не общается напрямую с API. Он может спросить у фабрики назначений о моих назначениях, и фабрика сначала проверит кеш. Если его там нет, он попадет в API, а затем кеширует результат. Тем не менее, если только я не позаботился о том, чтобы какие-либо создания / обновления также происходили через фабрику, кэш не обновлялся бы, если данные изменились.

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

I Не знаю, нравится ли мне идея сделать это на уровне веб-API. Часть меня чувствует, что API должен просто выполнять одну работу - помещать данные в базу данных и извлекать данные из базы данных. Возможно, он не должен принимать решения о том, хочет ли вызывающее приложение / пользователь использовать кэшированное значение или нет.

Мне бы очень хотелось услышать любое понимание вашего опыта реального мира с тем или другим - и если бы вам пришлось делать это снова, сделаете ли вы что-нибудь другое? Есть ли долгосрочные выгоды от одного решения?

1 Ответ

3 голосов
/ 23 марта 2020

Я бы (и сделал) сделать это в API по ряду причин:

  • Это делает API центральным местом, где вы запрашиваете данные.
    Как это решает, откуда берутся эти данные (кеш, БД, другой API и т. д. c), до API, и пользовательский интерфейс не нуждается в этом.

  • Делая API «мастер», вы можете создавать другие приложения, которые его используют, и данные всегда согласованы.

  • В какой-то момент вы все равно должны отправить данные в API, чтобы он сохраняется Один или несколько эквивалентных кэшей данных во внешнем интерфейсе будут неправильными в некоторой точке или не будут выровнены. Отправьте его в API и используйте то, что возвращает API. Не нужно думать об этом.

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

  • Сохраняет слои презентации легче.
...