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

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

Монолитные в смысле? Я юзаю репозитории для каждой модели

монолитные это когда в репозитории содержится более одного логического проекта

тут можно посмотреть вкратце о чем это: https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos

тут можно посмотреть вкратце о чем это: https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos

Ой, не обессудь, я не так понял. Я про паттерн

Привет всем. Вопрос есть по DI. Как лучше использовать? Di::get('modelFactory'); Di::getImplement('\Factory\Interface'); В первом случае используем соглашение о наименовании, но можно магией получать вроде $this->modelFactory; Во втором все нагляднее, по типу аргумента получаешь реализацию, но в коде будет явный вызов контейнера А вообще кто как пользует?

Привет всем. Вопрос есть по DI. Как лучше использовать? Di::get('modelFactory'); Di::getImplement('\Factory\Interface'); В первом случае используем соглашение о наименовании, но можно магией получать вроде $this->modelFactory; Во втором все нагляднее, по типу аргумента получаешь реализацию, но в коде будет явный вызов контейнера А вообще кто как пользует?

Я ваще статик оооч редко использую

Это условный код, сам не люблю статику

use Defr\FtlTheme\Page\PageSeeder;

$this->call(PageSeeder::class);

Типа статик тоже )))

Т.е. второй вариант. Вроде $this->getDi()->getImplement(AbstractSeeder::class);

Привет всем. Вопрос есть по DI. Как лучше использовать? Di::get('modelFactory'); Di::getImplement('\Factory\Interface'); В первом случае используем соглашение о наименовании, но можно магией получать вроде $this->modelFactory; Во втором все нагляднее, по типу аргумента получаешь реализацию, но в коде будет явный вызов контейнера А вообще кто как пользует?

Если у вас нет dependency-injection механизма (например, на рефлексии) и вы просто используете di-контейнер, я бы рекомендовал первый вариант с именоваными сервисами. Но это если количество таких сервисов небольшое, иначе нужно будет придумать и помнить слишком много имен.

Если механизм есть, то, только имена интерфейсов/классов.

А рефлексия не сильно много отожрет? Как-то опасаюсь ее в проде использовать.

Ну, надо хороший механизм с кешированием и компиляцией :)

Если механизм есть, то, только имена интерфейсов/классов.

Как только имена?

Без NS?

Или полные?

Полные

Я везде юзаю юз

Кроме пары мест

@agapovv , у вас di-контейнер, который вы сами наполняете, или абстрактная фабрика, которая по имени сервиса резолвит класс и создает его?

так а разве есть разница, как в сервис локатор закидывается объект?

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

так а разве есть разница, как в сервис локатор закидывается объект?

Фабрика - обертка же

так а разве есть разница, как в сервис локатор закидывается объект?

А оттуда как забрать? По названию класса или по солгасовваному именованному ключу?

так а разве есть разница, как в сервис локатор закидывается объект?

Она же методы в статики транслирует

Или я гоню?

Она же методы в статики транслирует

я не понимаю о чем ты

А оттуда как забрать? По названию класса или по солгасовваному именованному ключу?

насколько этот вопрос вообще принципиален? У вас мест использование этого должно быть крайне мало

ну, относительно конечно, проще всего по классу, потому что не надо выдумывать еще одно имя

Мест подключения мало, а вот сервисов в DI куча, и еще будет.

ну, относительно конечно, проще всего по классу, потому что не надо выдумывать еще одно имя

* по интерфейсу :)

так а разве есть разница, как в сервис локатор закидывается объект?

Никакой принципиальной, но если я сам создаю сервис-провайдеры, мне удобнее давать сервисам простые короткие имена, типа "db", "logger" и т. п. Если нет, то, по-моему, лучше использовать класснеймы (включая интерфейс-неймы)

Никакой принципиальной, но если я сам создаю сервис-провайдеры, мне удобнее давать сервисам простые короткие имена, типа "db", "logger" и т. п. Если нет, то, по-моему, лучше использовать класснеймы (включая интерфейс-неймы)

Я пользую длинные, но очень строгие по правилам названия

Никакой принципиальной, но если я сам создаю сервис-провайдеры, мне удобнее давать сервисам простые короткие имена, типа "db", "logger" и т. п. Если нет, то, по-моему, лучше использовать класснеймы (включая интерфейс-неймы)

чем это лучше Logger::class, которое еще и легко анализируется статически всякими ide/тулзами

С db и логгерам, кэшами все просто. А вопрос возникает, когда есть библиотека, которая, к примеру использует файбрику моделей, и клиенту надо заменить фабрику на свою.

вот в js/python у вас сервис локатор по файловой системе

а в пыхе проще по fqn

чем это лучше Logger::class, которое еще и легко анализируется статически всякими ide/тулзами

Вкусовщина, у меня нет аргументов. Так тоже ок. Кроме того, что, анализ вряд ли будет работать для возвращаемого значения, так что это не помогает.

Ну в целом, получается, что по названию интерфейсов. Сделать один сервис-фабрику Di, который будет отдавать конкретную реализацию. А если количество возрастет, заменить на механизм DI. Спасибо

Вкусовщина, у меня нет аргументов. Так тоже ок. Кроме того, что, анализ вряд ли будет работать для возвращаемого значения, так что это не помогает.

плюсом ориентирование на интерфейсы - заменяемость, мой код в приложении зависит от интерфейсов, а значит, когда я хочу что-то заменить, то я не думаю про какой-то там сервис в контейнере, а думаю про иную реализацию интерфейса

плюсом ориентирование на интерфейсы - заменяемость, мой код в приложении зависит от интерфейсов, а значит, когда я хочу что-то заменить, то я не думаю про какой-то там сервис в контейнере, а думаю про иную реализацию интерфейса

А у тебя для всего они есть?

А у тебя для всего они есть?

нет

Согласен, имя интерфейса универсальнее.

А у тебя для всего они есть?

Любая абстракция или даже конечный класс, в вобщем-то подойдет.

Любая абстракция или даже конечный класс, в вобщем-то подойдет.

Мне в скаффолде только для модели и репозитория создается. Я и не парюсь для других сущностей.

Как репозитоий заменить на другой в процессе выполнения?

setRepository метод ваще вроде

Как репозитоий заменить на другой в процессе выполнения?

Или ты про гит?

setRepository он же не статический? Вызывается откуда-то

А где ты менять собрался?

ERROR: S client not available

Там и вызывать надо

У меня в модели есть привязка

И еще в билдерах таблиц

И деревьев тож

Так-то да. А если подключать это все к другому, клиентскому, коду через композер. Как из него настроить репозиторий?

В каком то объекте

Классе

У меня этот объект - DI контейнер. Там и репозитории и сервисы и фабрики. Выбирал как получать из него. По имени интерфейса или ключу.

Там биндинги есть в контейнере?

В phalcon\di я не нашел. Вот свою реализацию и пилю.

А че, у тебя уже куча кода написана?

Угу, и не только мной )

Ухх

В phalcon\di я не нашел. Вот свою реализацию и пилю.

https://docs.phalconphp.com/en/3.2/di разве не то

вообще обсуждение пыховских библиотек оставлять в чатике пхп

О нем речь, только там биндингов я не вижу

вообще обсуждение пыховских библиотек оставлять в чатике пхп

Грань зыбка

вообще обсуждение пыховских библиотек оставлять в чатике пхп

Обсуждали DI. О phalcon речь зашла только для описания отсутствия функционала. Вдруг я слепой и не видел чего-то.

Хз, я там к ларкиным привык. Тем более юзаю апгрэйженый провайдер. Меня всем устраивает

Тут есть повернутые на SOLID ?

ну точнее, как реальны мир уживается с SOLID ?

по моим наблюдениям со скрпом

вообще хорошо уживается

не понимаю вопроса)

повернутых нет, но solid это хорошая штука которой выгодней придерживаться, чем не придерживаться, имхо

повернутых нет, но solid это хорошая штука которой выгодней придерживаться, чем не придерживаться, имхо

А как же Конь ?