Расположение кэшируемого кода в доменном дизайне - PullRequest
Новая
       19

Расположение кэшируемого кода в доменном дизайне

6 голосов
/ 08 января 2010

В приложении, которое соответствует дизайну, управляемому доменом, где у вас есть следующие виды понятий

  1. Репозиторий, который имеет доступ к базе данных
  2. Служба приложений, которая координирует взаимодействия между объектами и объектами значений и т. Д.

Куда бы вы поместили код кэширования для облегчения дорогостоящего вызова базы данных?

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

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

Ответы [ 2 ]

10 голосов
/ 08 января 2010

Замечательная особенность абстрактных репозиториев состоит в том, что вы можете использовать шаблон Decorator для реализации таких сквозных задач, как кэширование.

В качестве примера, учитывая интерфейс IMyRepository, вы можете создать MyCachingRepository, например, такой псевдокод: 

public class MyCachingRepository : IMyRepository
{
    private readonly IMyRepository repository;

    public MyCachingRepository(IMyRepository repository)
    {
        if(repository == null)
        {
            throw new ArgumentNullException("repository");
        }

        this.repository = repository;
    }

    public Foo SelectFoo(int id)
    {    
        Foo foo = ... // attempt to get foo from cache

        if // foo is not it cache
        {
            foo = this.repository.SelectFoo(id);
            // save foo in cache
        }
        return foo;
    }
}

В этом примере GetFoo определяется IMyRepository. Обратите внимание, что оформленный репозиторий вызывается только в том случае, если элемент не найден в кэше.

Это следует принципу Single Resposibility , потому что реальная реализация кэширования может концентрироваться на извлечении и сохранении данных, тогда как декоратор кэширования может концентрироваться на кэшировании. Это позволяет вам изменять их независимо друг от друга.

В нашем текущем проекте мы использовали этот подход, и что особенно приятно, мы могли бы сделать это в качестве запоздалой мысли, даже не касаясь оригинальных репозиториев. Это в духе Открытого / Закрытого Принципа .

2 голосов
/ 08 января 2010

Я бы положил это в репозитории. Репозитории должны определяться договором, а использование кэша должно быть скрыто за этим контрактом, чтобы он был прозрачен для потребителя репозитория.

...