Кеширование: репозиторий или модель?

Question

[D3lphi]

Уже не раз задавался вопросом, читал ответы на тостере по этому поводу, но не разу не видел однозначного ответа. Так вот, вопрос: Где правильнее, с точки зрения архитектуры (В Laravel приложении), будет хранить логику кеширования (Например, если есть данные в кеше, вытащить их, иначе отдать данные из БД) в репозитории или в модели? Вроде, как модель отвечает за работу с данным, хотя с другой, слышал мнение, что модель - это простой POPO.

Answer 1

[Falseclock]

Я написал свой драйвер еще 10 лет назад и проблем не знаю.

$sth = $db->prepare("SELECT * FROM foo");
$sth->cache("Foo:*");
$sth->execute();

метод execute проверяет было ли значение ключа кэша и если есть, дергает данные из кэша. Если там пусто, делает запрос к базе. 1 раз написал и забыл на долгие годы.

Без указания кэша данные всегда будут дергаться из базы

$sth = $db->prepare("SELECT * FROM foo");
$sth->execute();

Comments

[D3lphi]

Спасибо за совет, но мой вопрос находится в рамках Laravel приложения, следовательно, нужно использовать ORM.

[Falseclock]

D3lphi: к сожалению не знаю что такое Laravel. Никогда не любил пользоваться тем, что не дает тебе возможность фантазировать и реализовывать как зовет сердце.

[D3lphi]

Не хочу затевать холивар, скажу только, что тот момент, когда я писал свои велосипеды уже прошёл. Считаю, что глупо в 2017 году не использовать фреймворк для разработки веб-приложений, ведь он дает огромное количество преимуществ, а простора для фантазий в любом фреймворке достаточно. Если вы не знаете, что такоеLaravel, как вы можете писать "не дает тебе возможность фантазировать и реализовывать как зовет сердце"?

[Falseclock]

D3lphi: да я даже не пытаюсь холиварить... я за 10 лет опыта с PHP написал столько классов, методов и библиотек, что мне ни какой фрейм не нужен.. все уже готово. Правда только сейчас начал публиковать свои наработки. Например как из 1C базы синтаксисом SQL вытаксивать данные через ODATA. Никто еще на додумался это реализовать, что весьма странно.

Answer 2

[Дмитрий Евграфович]

Над репозиторием. Я делал следующим образом: пишу репозиторий, его интерфейс, затем через сервис контейнер привязываю интерфейс к реализации. Позже другой код-код-код, затем спустя некоторое время уже пишу слой кэша и всю логику кэширования. Кэширующий класс наследует тот же самый интерфейс и после написания подставляется в сервис-контейнер вместо текущей реализации. Можно кэширующий слой поставить еще выше, все от вашей архитектуры зависит (поэтому однозначного ответа тоже не будет), но ниже лично я смысла не вижу, может просто примеры не попадались, когда это требовалось. А архитектура в рамках ларавела четко не задана. Есть некие инструменты, описанные в документации, но вы можете строить архитектуру так, как вам кажется наиболее правильным. Я в свое время проникся статьей о гексагональной архитектуре и сейчас изложенные в ней принципы мне очень и очень нравятся (не сказать, что там что-то новое написали, просто разложили по полочкам внятно уже существующие вещи).