как-то так я тебе отвечу на сервисы BookFiller

как выше сказал Сергей, всё зависит от задачи. Если планируется использование исключительно mysql базы, то драйвер mysqli вполне рабочий вариант

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

как раз только в сайте-визитке может понадобитьс смена субд)

я пока ни разу такого не встречал)

на реальном проекте такое случится +\- никогда) ибо это если и не невозможно, то крайне сложно. к тому же, так или иначе, но люди с pdo всё равно используют специфичные для конкретной субд операции.

как-то так я тебе отвечу на сервисы BookFiller

Ну это пример же. Так ты мне уже отвечал на подобный пример. Пусть будет BookShelfCreatorService, суть вопроса не поменялась.

на реальном проекте такое случится +\- никогда) ибо это если и не невозможно, то крайне сложно. к тому же, так или иначе, но люди с pdo всё равно используют специфичные для конкретной субд операции.

тут однозначно ++++

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

Ну это пример же. Так ты мне уже отвечал на подобный пример. Пусть будет BookShelfCreatorService, суть вопроса не поменялась.

с такими сервисами тоже смотри ту картинку. Ну либо опиши чем занимается BookShelfCreatorService

в моем понимании для создания book shelf нужна либо другая "сущность" (в общем смысле, какой-то объект, сервис или сущность доктрины не важно)

с такими сервисами тоже смотри ту картинку. Ну либо опиши чем занимается BookShelfCreatorService

По запросу создает "полку" из переданного ему списка книг.

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

и да это абстрактная полка в вакууме или реальный пример?

и да это абстрактная полка в вакууме или реальный пример?

Это абстрактная в вакууме.

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

Что ты имеешь в виду? Кто будет дергать его метод createBookshelfFromBooksList?

вроде того

ладно, дабы не повторяться - смотри видос

https://www.destroyallsoftware.com/talks/boundaries

Контроллер, например или команда консольная.

а почему эта логика не может находиться в классе Bookshelf?

а почему эта логика не может находиться в классе Bookshelf?

Да, тут ты прав, пример неудачный.

По запросу создает "полку" из переданного ему списка книг.

содержимое примерно опиши

а ну вы уже пришли к консенсусу что этот сервис не очень то и нужен)

Ок, пример получше, но тоже сферический в вакууме. Сущность Ticket, с методом cancel и свойством cancelation. Сопутствующий сервис TicketCancelationService и методом cancelAllExpired, например. Вопрос. Где предпочтительнее протестировать логику метода cancel, если она сложная. В тестах для сущности TicketTest или в тестах для сервиса?

cancellation -> cancelled? статус имеешь ввиду?

cancellation -> cancelled? статус имеешь ввиду?

Нет, объект TicketCancellation

VO какой-нибудь?

Ок, пример получше, но тоже сферический в вакууме. Сущность Ticket, с методом cancel и свойством cancelation. Сопутствующий сервис TicketCancelationService и методом cancelAllExpired, например. Вопрос. Где предпочтительнее протестировать логику метода cancel, если она сложная. В тестах для сущности TicketTest или в тестах для сервиса?

а что делает TiketCancelationService?)

у меня вся логика была бы внутри Ticket)

(возможно, если вся логика относится именно к билету)

а у меня внутри сущности выше Ticket (доска там или что-то вроде)

ну именно cancelAllExpired

ну именно cancelAllExpired

да, это у оунера твоих тикетов надо)

да, это у оунера твоих тикетов надо)

Серьезно? Предлагаешь мне в сущность инжектить её репозиторий?

Серьезно? Предлагаешь мне в сущность инжектить её репозиторий?

ммм.... еще раз - опиши юзкейс. что есть, что должно быть и нахера тебе репозиторий?

овнер твоих тикетов - к примеру, доска или проект

ммм.... еще раз - опиши юзкейс. что есть, что должно быть и нахера тебе репозиторий?

Репозиторий мне тут, что бы метод сервиса cancelAllExpired выбрал бы из БД нужные сущности Ticket

Репозиторий мне тут, что бы метод сервиса cancelAllExpired выбрал бы из БД нужные сущности Ticket

у Ticket есть владелец?

какая-то сущность которая хранит коллекцию тикетов этих

или речь идет о каких-то batch операциях?

у Ticket есть владелец?

Предположим, что нет. Но он связан с другими сущностями.

Предположим, что нет. Но он связан с другими сущностями.

если нет - то мы можем говорить только о batch операции

или речь идет о каких-то batch операциях?

В том числе

что в том числе? так есть владелец или нет?)

что это за тикет вообще?

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

В том числе

пойдем от другого - ты мокаешь сущности?)

ну вот захотел ты сервис свой этот потестить - будешь ли ты мокать сущности?

пойдем от другого - ты мокаешь сущности?)

Нет, использую sqlite

Нет, использую sqlite

то есть мы говорим о интеграционных тестах нежели юнитах

(ну то есть у тебя не один юнит в изоляции а много юнитов и даже целая база данных)

то есть мы говорим о интеграционных тестах нежели юнитах

Нет, это больше юнит тесты, просто решили не мокать репы.

Нет, это больше юнит тесты, просто решили не мокать репы.

больше, меньше..... если юнит в тесте не один, если все зависимости не подменены на какие-то заглушки/моки - то это не юнит тест.

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

больше, меньше..... если юнит в тесте не один, если все зависимости не подменены на какие-то заглушки/моки - то это не юнит тест.

Вот спасибо большое!

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

Именно эта мысль меня и мучала.

Вот спасибо большое!

я повторюсь, важно что бы мы понимал о чем мы говорим. Интеграционные тесты - это отдельная песня. Там чуть другие принципы и чуть другие загоны.

юниты чувствительны к связанности, к количеству зависимостей. Много зависимостей - юниты становятся хрупкими (как и клиентский код завязанный на эти юниты). И именно это является той причиной почему многие не умеют в юнит тесты. Потому что мало просто тесты научиться писать

интеграционные же тесты больше чувствительны к фикстурам, а на качества кода им пофигу

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

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

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

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

короч в этом ключе следует делать так как тебе удобнее и все. Много юнитов с такой декомпозицией не написать, пирамида тестов уже не ок

p.s. я думаю эта пирамида перевернута у 90% людей, но лучше хоть какие-то тесты

Спасибо, обсудим с командой.

https://vimeo.com/80533536

ERROR: S client not available

можешь с ними посмотреть обсудить)

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

потому.... может не понравиться)

Есть для пхп какая-нибудь штука для определения (boot) темплейтов сообщений в rabbit mq? Проще говоря какой то спецификатор жсон структуры

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

Что правильнее? Выносить время жизни в константу(при том что юзаться будет 1 раз в репозитории) или хардкодить числом? $qb ->getQuery() ->useResultCache( true, self::PAYOUT_STATISTIC_TTL) или $qb ->getQuery() ->useResultCache( true, 3600)

а то у меня ту мини холливар с коллегой

константа,имхо

изменил один раз, изменилось во всех местах

а не полез править везде, где оно юзалось в каких репозиториях/сервисах/менеджерах и тп

это да, если юзается не раз

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

это да, если юзается не раз

В любом случае константа, потому, что у неё есть имя.

даже если раз - проще читать/понять шо это за хрень

тенкую

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

плюсую за имя - магические числа в коде есть зло

открываешь такой легаси код а там идет выражение и в конце него 54

ненене

и сиди гадай, почему 54, что это значит откуда оно и тп

42

ну да, 42

https://paste.laravel.io/df73af1f-23e0-4f06-97f4-4cb39be71a6c как такую лапшу бы переделать? есть какие то практики, или паттерны?

https://paste.laravel.io/df73af1f-23e0-4f06-97f4-4cb39be71a6c как такую лапшу бы переделать? есть какие то практики, или паттерны?

array_replace

https://paste.laravel.io/df73af1f-23e0-4f06-97f4-4cb39be71a6c как такую лапшу бы переделать? есть какие то практики, или паттерны?

для isset есть ?? — оператор такой

для isset есть ?? — оператор такой

ему нужен array_replace

https://paste.laravel.io/df73af1f-23e0-4f06-97f4-4cb39be71a6c как такую лапшу бы переделать? есть какие то практики, или паттерны?

использовать dto

ему нужен array_replace

хм ... а как его тут применять?)

хм ... а как его тут применять?)

подумай)

да пздц, устроился на работу. тут такой лапшекод в некоторых местах

поплакал, теперь думаю как переделать

хм ... а как его тут применять?)

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