Шаблон репозитория - Кэширование - PullRequest
29 голосов
/ 09 августа 2010

Я не уверен, где мне следует реализовать кэширование в моем шаблоне хранилища.

Должен ли я реализовать его в сервис-логике или в хранилище?

GUI -> BusinessLogic (Услуги) -> DataAccess (Репозитории)

Ответы [ 2 ]

49 голосов
/ 18 октября 2011

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

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

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

24 голосов
/ 09 августа 2010

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

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

...