Я бы тоже не хотел, это чисто пример чтобы люди поняли :)
Ага, вы тоже советуете делать 1 метод и параметром. Кстати, методов будет несколько потому как не выйдет сделать REST API, слишком уж сложные ресурсы. Точнее сделать все же можно, но под копотом будет забей.
Сергей Протько:
> если вам не нужно кеширование - вы не делаете декоратор.
сейчас так и есть, временно.
В ответе вы написали
> Я предлагаю вам вооружиться DependencyInjection
я пытаюсь понять как в данном случае можно его использовать, но не понятно. Что вы имели ввиду?
Сергей Протько: не наследование. Т.е. нужно для каждого базового класса создать кэширующий класс с теми же методами, даже если кэширование не требуется?
Сергей Протько: хорошо, решил попробовать di, но столкнулся с тем что базовый класс не требует ничего в конструкте, а кэширующий требует этот базовый класс. Как тогда назначить зависимость?
из доки пример не показывает как передать параметры в BookingService
\Yii::$container->set('app\components\BookingInterface', 'app\components\BookingService');
Никита: нет, я не это говорил. Есть модель и есть сервис, который буквально манипулирует ею. А вся работа идет только с сервисом, детали работы модели не знаем.
Никита: перечитал ваш ответ, не соглашусь. Я считаю что сервисы (компонеты) должны быть главнее моделей и уметь ими манипулировать. В таком случае не будет возникать вопросов "как из модели вызвать компонент".
Лев Ртутин: В теории все так и есть. Но мы живем в практике :)
Проблема в том что новые фреймворки не только меняют название методов и классов. Что если изменится что-то более крупное? Вот тут, скорее всего, придется переписывать не только обертку, но и код за ней.
В общем, если вам хочется реализовать обертку и вы знаете что проект не придется поддерживать (в плане функционала), то можно и написать, но я бы не советовал, не оправдано.
Воу-воу) Итак.
> почему вы решили назвать репозиторий для продукта CatalogProductRepository.
CatalogProductRepository
продукта репозиторий
Вообще, в моем случае CatalogProductRepository ассоциация к сущности в API. Она там так и называетя.
На счет DependencyInjection.
Проблемы 2:
1. Нужно покопаться есть ли к yii2 эта штука и как реализовывается.
2. Если я правильно понял принцип, то в случае с DependencyInjection я не смогу вызвать в одном случае вызвать метод с кэшированием, а в другом - без.
Собственно, поэтому выходом является фабрика
> И что это за true
с флагом для возврата модели с кэшированием или без.
Сергей Протько: Маджента не плоха... Но у нее есть ряд проблем:
1) да, это зависимости и такая структура кода что ничего не понятно;
2) про доку можно забыть, ее нет;
3) куча багов. реально, каждый второй issue: https://github.com/magento/magento2/issues
4) вроде все гибкое, но в моем случае оказалось что к 1 заказу нельзя несколько shipping addresses, это фейл.
Сейчас юзаем систему больше как хранилище и работаем через API.
Сергей Протько: Я немного работал с Magento 2, так вот там вроде dependency injection что называется, по полной. Да, там как раз и фабрики динамические. Только вот там тысячи файлов и в __construct по 50 строк бывает. Продолжим дальше искать лучшие реализации.
Сергей Протько: Я решил выполнить библиотеку для работы с API в виде моделей в некотором смысле как AR https://github.com/springimport/yii2-magento2-acti...
Поверх простых моделей есть более умные (их не в репо) - у них уже появляются методы вроде getCustomerById(). Собственно, некоторые методы нужно кэшировать.
> И вот для этих "файнедров" при наличи у них интерфейса мы можем написать "декоратор" который будет заниматься кешированием.