Причем всё на ::getInstance()

Ок, вот db это именно подключения к базе? Вместе с паролями и базами данных?

Или всё таки DB это просто обёртка над базой, а настройкой подключений владеет само приложение?

Ну, пароли на проекте, конечно, и не под git

Настройка и подключение — тоже ядро.

На подпроекте только конфиги

Ян, на митинг, епт!

Хуитинг)

Все ждут тебя :)

Или всё таки DB это просто обёртка над базой, а настройкой подключений владеет само приложение?

На подпроектах для таких вещей только конфиги. Из кода можно вызывать, скажем, Redis::getInstance() и работать с редисом.

На подпроектах для таких вещей только конфиги. Из кода можно вызывать, скажем, Redis::getInstance() и работать с редисом.

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

но мне все же интересно послушать почему было написано это самое "ядро"

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

Почему? Я бы мог хранилище заинтерфейсить, например. Или это бессмысленно?

Почему? Я бы мог хранилище заинтерфейсить, например. Или это бессмысленно?

заинтерфейсить - бессмысленно

На подпроектах для таких вещей только конфиги. Из кода можно вызывать, скажем, Redis::getInstance() и работать с редисом.

Раз так то никто не мешает добавлять ваше "ядро" в приложение через composer, указывая версию в ввиде ревизии или тэга. И использовать его на равне с другими. Остальное всё тоже подключать через composer. У каждого проекта свой список зависимостей, и соответственно изменения в одном не влияют на изменения в другом. .... profit

лучше задаться вопросом "что тебе сейчас мешает и что можно с этим сделать".

Почему? Я бы мог хранилище заинтерфейсить, например. Или это бессмысленно?

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

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

лучше задаться вопросом "что тебе сейчас мешает и что можно с этим сделать".

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

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

мы уже выяснили что тебе никто не мешает это делать

И избавиться от повсеместных ::getInstance()

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

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

И избавиться от повсеместных ::getInstance()

заверни в фабрики

возьми какой PHP-DI

и не парься

return [ Foo::class => function () { return Foo::getInstance(); } ]

и радуйся

return [ Foo::class => function () { return Foo::getInstance(); } ]

+1

$container->get(Foo::class)

и соответственно уже можно будет инджектить это куда надо, и автовайринг есть

а далее уже адаптеры, интерфейсы....

модульность

крути верти как хочешь

всеравно жизнь боль

Боль это да)

Благодарю за наводку, очень полезно.

тут есть люди которые по многу API пишут?

а то мне общаться нескем

только вон @YuraLukashik

тут есть люди которые по многу API пишут?

Когда то я был таким =(

Сейчас уже увы только для себя =(

меня дико удручает ситуация с инструментами для PHP

все какое-то... не такое

да норм)

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

в php?

норм же

В php

Не норм

а что не норм?

В php

https://github.com/elazar/asynchronous-php

Вот пример. Я хочу взять из хранилища некую сущьность с данными. И для этого мне чуть ле не свлю ORM/ODM писать нужно

Что бы модель не знала где и как она храниться

Ничего готового асинхронного нет

обычная хорошая орм мало где есть

а ты хочешь асинхронную

Ну так-то доктрина меня почти всем устраивает

Да и доя key-value есть решения норм

ну меня слабо

у меня как-то раз была безумная мысль сделать доктрину асинхронной

для этого не много надо

драйвер есть

для базы

просто берешь и делаешь свой драйвер для dbal

его ровно впилить

Ха

ERROR: S client not available

Не просто увы

почему не просто?

довольно просто

смотря с чем сравнивать

если с нуля орм

саму ORM причем делать асинхронной смысла ровным счетом никакого нет.

то просто изичка

асинхронным надо делать только взаимодействие с I/O

а всякие там юнит оф ворки пусть себе синхронно гоняются

асинхронным надо делать только взаимодействие с I/O

Именно

ну да, но из-за этого проектировать по-другому нужно

Там работы ужас сколько

уже сделано

I/O

Я думал по быстрому что-то типа https://github.com/bravo3/orm/ переписать на асинхронный лад

Но это же треш

https://github.com/doctrine/dbal/issues/2404

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

но сделать свой драйвер тебе никто не мешает)

Я вот честно сказать к стыду своему не в курсе как работае async драйвер mysql в php Он на callbacks основан?

Так драйвер нужно ещё использовать правильно

промисы есть

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Driver/Mysqli/MysqliConnection.php

~300 строк кода

Тебе промис драйвер возвращает а не значение что ты ожидаешь

да

можно и колбеками

при помощи yield можно сделать так, что бы драйвер возвращал значения

но прерывал выполнение

и давал поработать кому-то еще

при помощи yield можно сделать так, что бы драйвер возвращал значения

Это чуть чуть но лож

при помощи yield можно писать в синхронном стиле