Шаблон хранилища - кэширование

Ответ 1

Я бы обработал его на уровне доступа к репозиторию/доступу к данным. Объяснение состоит в том, что дело не в бизнес-уровне, откуда можно получить данные, это задача репозитория. Затем репозиторий решает, откуда взять данные, кеш (если он не слишком старый) или из источника данных в реальном времени на основе обстоятельств логики доступа к данным.

Это вопрос доступа к данным более чем вопрос бизнес-логики.

Ответ 2

Хорошая идея не вставлять логику кэширования непосредственно в ваш репозиторий, поскольку это нарушает принцип единой ответственности (SRP) и разделение проблем. SRP по существу утверждает, что у ваших классов должна быть только одна причина для изменения. Если вы столкнетесь с проблемами политики доступа к данным и кэширования в том же классе, то, если любой из них необходимо изменить, вам нужно коснуться класса. Вероятно, вы также обнаружите, что нарушаете принцип DRY, так как легко использовать логику кэширования среди множества различных методов репозитория, и если какое-либо из них необходимо изменить, вам придется изменить многие методы.

Лучший подход заключается в использовании шаблона Proxy или Strategy для применения логики кэширования в отдельном типе, например CachedRepository, который затем использует фактический db-центричный репозиторий по мере необходимости, когда кеш пуст. Я написал две статьи, демонстрирующие, как реализовать это, используя .NET/С#, которые вы найдете в моем блоге, здесь:

• http://ardalis.com/introducing-the-cachedrepository-pattern
• http://ardalis.com/building-a-cachedrepository-via-strategy-pattern

Если вы предпочитаете видео, я также описываю шаблон в шаблоне Proxy Design на Pluralsight, здесь:

• http://pluralsight.com/training/courses/TableOfContents?courseName=patterns-library