А так? class Flush extends EntityManager

Ах да. Поэтому

ну он сделал то что ему обьяснили 909))))

А так? class Flush extends EntityManager

дай определение слову "изоляция" и что от чего мы хотим изолировать)

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

эх надо управженение разработать из двух фаз. Первая простая а вторая знакомит людей с болью

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

@Eraice

Он на англ не умеет

Подобный подход применяется в этой пасте: https://github.com/codedokode/pasta/blob/master/arch/di.md Как по мне - отличная статья для знакомства с DI. Сначала рассматриваются примитивные способы работы с зависимостями, указаны недостатки, далее объясняется какую задачу решают контейнеры и в конце небольшой практический пример.

она на рус

Классная статья спасибо большое

Почитал с удовольствием

Реально классно описано четко ясно и по полочкам все

> Принцип одной обязанности

мило)

вообще DI больше про open/close

Новичку вряд ли помогут такие подробности.

ну тогда и про принцип "одной обязанности" тоже не стоит)

вообще как бы мысли полезные но немного каша...

Главное, как по мне, подтолкнуть, чтобы прочитавший задумался и начал уже сам ресёрчить. А там уже сам пусть решает подходит SRP или нет. Я встречал проекты, которые были написаны сениорами с 8+ годами опыта, и там даже сервисами/менеджерами не пахнет, портянки в контроллере тяжело переиспользовать и тестировать в изоляции.

Это становилось причиной багов, замедляло скорость реализации фич

Главное, как по мне, подтолкнуть, чтобы прочитавший задумался и начал уже сам ресёрчить. А там уже сам пусть решает подходит SRP или нет. Я встречал проекты, которые были написаны сениорами с 8+ годами опыта, и там даже сервисами/менеджерами не пахнет, портянки в контроллере тяжело переиспользовать и тестировать в изоляции.

а что если рассказать "как так получилось что если загуглить урок по php с классами то первое чему тебя научат это сингелтон с getInstance для работы с зависимостями и почему и как можно придти к DI)?

так сказать немного истории)

допустим я могу исправить проблемы с registry и service locator описанные в статье и при этом не применять DI)

Я сам не знаю почему так получилось, но у меня есть предположения - низкая грамотность PHP-разработчиков, ниша для которой изначально создавался язык - по-быстрому клепать простенькие сайтики

Я сам не знаю почему так получилось, но у меня есть предположения - низкая грамотность PHP-разработчиков, ниша для которой изначально создавался язык - по-быстрому клепать простенькие сайтики

не совсем.

допустим я могу исправить проблемы с registry и service locator описанные в статье и при этом не применять DI)

Опиши, интересно

Но я посоветую посмотреть на это всё с позиции новичка, который о DI ни слухом ни духом

1. DI контейнер это сложно если не юзать готовый 2. простой DI контейнер который можно скорее всего будет использоваться как service locator по итогу и не так удобно как нормальный SL тот же 3. SL вполне годный вариант если у тебя он не один на проект. А как и задумывалось - на каждый сервис свой локатор. В простых "сайтиках" не так уж и много зависимостей выходит. 4. сингелтоны начали юзать потому что это проще чем нормальный SL 5. ты когда-нибудь юзал PEAR во времена когда небыло composer?) 6. github появился всего-то лет 11 назад. php5 появился раньше. 7. вроде как в php4 был уже статик, не помню точно.

ты не забывай что помимо гринфилд проектов есть еще суровый процедурный легаси, где SL зайдут только в путь

Database::get()

и вот у тебя есть инстанс какого-то типа

Database::setInstance(ConnectionInterface $db)

и вот у тебя уже есть возможность нормально конфигурить

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

представь что будет если разработчики которые умеют только DI и считают что все остальное - плохо (а именно так статья и говорит им) за немалые деньги начнут работать над легаси 10-ти летней давности

они сразу попробуют туда контейнер запихнуть и как бы сделают только хуже0

или какой-нибудь yii причесывать 3-х летней давности

Идея, как по мне, в том, чтобы зависимости пропихивать "сверху", для этого не обязательно нужен контейнер. Ну и в простых случаях без автовайринга контейнер будет очень простым как Pimple

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

Идея, как по мне, в том, чтобы зависимости пропихивать "сверху", для этого не обязательно нужен контейнер. Ну и в простых случаях без автовайринга контейнер будет очень простым как Pimple

сверху это да, а почему?

Чтобы подменять в тестах

Чтобы подменять в тестах

http://devhumor.com/content/uploads/images/February2017/tests.png

Сейчас поддерживаю проект как раз на Yii где куча всяких парсеров и очередей. Запускается из веб-интерфейса, тестировать что-то в изоляции очень тяжело

А тестировать надо, так как логики много

Из веб интерфейса запускается, так как логика в контроллерах

ну так это проблема исключительно разделения ответственности. DI тут не особо поможет)

я могу тебе такой же нетестируемый продуктик запилить и с DI)

Ну а как мокать HTTP клиент без DI? Особенно когда "HTTP клиент" это вызов curl_* функций?

Ну а как мокать HTTP клиент без DI? Особенно когда "HTTP клиент" это вызов curl_* функций?

я тебе показал как это делать с сервис локатором)

HttpClient::setInstance()

Подменой dns :)

Подменой dns :)

тоже верно

ложишь файлики с респонсами и подсовываешь курлу

вообще задумайся вот о чем

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

сколько у этого класса ответственностей?

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

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

а первое в изоляции смысла нет проверять

не стоит мокать то что ты не контролируешь

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

Она же устарела (

Она же устарела (

Слушай, тебе уже сказали, куда смотреть: документация. Если вообще туго, иди на сайт и проходи курсы, можно бесплатно в рид-онли, без видео. Если не получается, гугли. Если не можешь нагуглить, перефразируй вопрос и гугли еще раз. Потом уже задавай вопросы) https://knpuniversity.com/

ERROR: S client not available

не стоит мокать то что ты не контролируешь

А можно еще пример один, пожалуйста, с тем что лучше не мокать) Может из реальной жизни)

А можно еще пример один, пожалуйста, с тем что лучше не мокать) Может из реальной жизни)

http://blog.thecodewhisperer.com/permalink/beyond-mock-objects

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

можешь еще погуглить на тему "dependency as code smell"

Может нубский вопрос, но как красиво вытягивать количество по ассоциациям, при выводе коллекции? $this->getMessages()->count() в коде красиво выглядит, но создает запрос каждый раз, при выводе коллекции. Ткните в какой-то best practices где это описано, плз. Т.к. видел что народ как-то через массивы извращается, но имхо не красиво оно.

Может есть возможность этот count вытащить преждевременно. Смотрел extra_lazy, там не нашел

Запрос пиши

Она же устарела (

С чего ты взял ?

Запрос пиши

Сюда написать ? Я понимаю как запрос писать, но все доп.поля с выборки игнорируются при гидрации

та не сюда) не игнорируются, добавь в селект алиасы таблиц)

-select(a, b, c)

->createQueryBuilder('u') ->join('u.contacts','uc') ->addSelect('COUNT(uc) as contactsCount') ->groupBy('u.id') ->getQuery()->getResult();

Так?

-select(a, b, c)

Создавал даже гетеры и сетеры в entity, setContactsCount, getContactsCount

А оно тужа не мапится

Или я дибил?

->createQueryBuilder('u') ->join('u.contacts','uc') ->addSelect('COUNT(uc) as contactsCount') ->groupBy('u.id') ->getQuery()->getResult();

Add select

Сеттеры не помогут )))

Add select

Там есть addSelect

Сеттеры не помогут )))

А что тогда поможет? )

тут я ща не уверен, но кажись если ты просто добавишь uc в селект то count не будет добавлять еще один запрос

тригеры в бд на инсерт/делейт и соунт поле в нужной таблице.

тут я ща не уверен, но кажись если ты просто добавишь uc в селект то count не будет добавлять еще один запрос

Да, но и каунт красиво не достать, без операций с резульаттом, и ручного мапинга

тригеры в бд на инсерт/делейт и соунт поле в нужной таблице.

Тригеры зло!

Тригеры зло!

обоснуй

обоснуй

Логика должна быть описана в одном месте, если она раздлена на 2 места, тогда ее трудно поддерживать. Елси ты что-то поменял в коде, тебе надо помнить за все тригеры которые есть в базе, и не забыть поменять их.

Да, но и каунт красиво не достать, без операций с резульаттом, и ручного мапинга

в addSelect пихаешь 'u' чтобы явно было приджойнено и $this->getMessages()->count() не будет отправлять запрос

Логика должна быть описана в одном месте, если она раздлена на 2 места, тогда ее трудно поддерживать. Елси ты что-то поменял в коде, тебе надо помнить за все тригеры которые есть в базе, и не забыть поменять их.

ну засунь это в сервис которй за круд данной зоны отвечает, все будет в одном месте :)

->addSelect('COUNT(uc) as contactsCount') это говно не будет гидрироваться

в addSelect пихаешь 'u' чтобы явно было приджойнено и $this->getMessages()->count() не будет отправлять запрос

В таком случае, вытянет все записи, а если их там 1000-2000?

будет массив с объектом и эл-ом contactsCount

В таком случае, вытянет все записи, а если их там 1000-2000?

тогда отдельный запрос