Кэширование репозитория, домена или приложения касается?

Question

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

Мое решение разделено следующим образом:

MyApp.Infrastracture
MyApp.Repositories
MyApp.Domain
MyApp.WebApplication

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

Кроме того, кэширование не является концепцией домена первого класса, поэтому не имеет естественного соответствия уровню домена.

Что делать?

Answer 1

Это касается всего вышеперечисленного.

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

Answer 2

Вы отметили

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

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

Как указывал @Oded, кэширование действительно может происходить где угодно, и вы, вероятно, обнаружите, что реализуете его во многих местах.если производительность является проблемой, и каждое место может сделать это по-своему.Например, вы можете кэшировать результаты определенных запросов в вашем домене, или вы можете кэшировать целые HTML-ответы.

Межуровневая координация приходит, потому что кеши могут быть довольно утечкой абстракции.Если ваши доменные объекты кэшируются, когда они должны быть кэшированы?Что если один поток использует кэшированный объект, а другой - нет?Что если вы кэшируете результаты запроса, но базовые объекты с тех пор изменились?Когда делать недействительными и как сделать недействительными являются сложными вопросами, как с точки зрения инфраструктуры, так и с точки зрения бизнеса.Устаревшие запросы не всегда плохи.

Answer 3

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

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

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

Answer 4

Кэширование может быть распределено по слоям, иногда кеширование может быть автоматически достигнуто на уровне домена, если вы используете ORM, такой как Nhibernate, который поддерживает кэширование нескольких уровней.На верхних уровнях это может быть основано на требованиях, например, при загрузке пользователя система загружает функции, которые пользователь может выполнять, затем она может быть кэширована на уровне приложения.Так что все зависит от приложения.