А как правильно?

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

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

И как вы рефакторите? Выбираете только реально нужные данные ?

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

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

+

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

особенно если захотите реакт изоморфы всякие

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

Есть линк на github где это глянуть можно? На словах не совсем понятно.

Есть линк на github где это глянуть можно? На словах не совсем понятно.

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

это могут быть либо дтошки, либо просто массив

Есть линк на github где это глянуть можно? На словах не совсем понятно.

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

почему это нельзя сделать потом. при рефакторинге? ;)

особенно если захотите реакт изоморфы всякие

Не видел ещё реакт апп на симфонии )

https://github.com/za4me/symfony.dev/blob/knp/app/Resources/views/genus/list.html.twig в твоем случае это будет чето в духе $viewData = ['genuses' => array_map(function(Genus $genues){ return ['name' => $genus->getName, 'speciesCount' => $genus->get...]; },$genuses];

Не видел ещё реакт апп на симфонии )

надеюсь скоро будет у нас) пока только в песочнице эксперементировал

https://github.com/za4me/symfony.dev/blob/knp/app/Resources/views/genus/list.html.twig в твоем случае это будет чето в духе $viewData = ['genuses' => array_map(function(Genus $genues){ return ['name' => $genus->getName, 'speciesCount' => $genus->get...]; },$genuses];

т.е. соль в том что сразу в контроллере видно какие поля используются в шаблоне?

да

ну и меньше соблазн будет сделать каких-нибудь логических блоков в шаблоне

что тоже бывает доставляет неприятностей)

В итоге в view прилетает просто массив данных и просто идёт его перебор, например

да

с тем же успехом ты можешь отдать json и отрендерить на клиенте

А не массив сущностей и их перебор

в общем представляй что twig это такой же фронтэнд, который не знает о твоих сущностях и прочем булшите

Это все для того чтобы во вьюхе не пошли перебором по связям и не слелали 1к кверей на страницу ?))

Это все для того чтобы во вьюхе не пошли перебором по связям и не слелали 1к кверей на страницу ?))

ну такое реже бывает, но да. тоже вполне кейс

Это все для того чтобы во вьюхе не пошли перебором по связям и не слелали 1к кверей на страницу ?))

А разве при передачи в view массива сущностей запрос будет идти из view?

там могут быть lazy связи

А разве при передачи в view массива сущностей запрос будет идти из view?

Ну ті перкдаешь лейзи

А, вы за связи

Вот такая проблема у меня ща с апи

А, вы за связи

Ну в шаблоне кто-то сделает user.team.users.blabla.category.users

И гг вп

Вообщем сегодня профит такой: Передавать в шаблоны сущности нельзя, а лучше подготавливать данные в контроллере. Не совсем понял конечно мысли о доктрине и UoW, это я думаю со временем.

Ну в шаблоне кто-то сделает user.team.users.blabla.category.users

А при подготовленных данных это просто не смогут сделать.

Вообщем сегодня профит такой: Передавать в шаблоны сущности нельзя, а лучше подготавливать данные в контроллере. Не совсем понял конечно мысли о доктрине и UoW, это я думаю со временем.

Можно, если нет времени

Ну и зависит от проекта и тд

А при подготовленных данных это просто не смогут сделать.

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

Так то можно все что угодно :)

Ну не, просто если ты и вью делаешь сам то беды не сделаешь

Ну типа все зависит от проекта, но бестпрактис такой.

Главное что есть обоснование этого best practice, а не только потому что "парни из чатика сказали"

Вот я сам на проекте

У меня нет времени на это

Главное что есть обоснование этого best practice, а не только потому что "парни из чатика сказали"

ну это просто пример из опыта, от чего у нас попаболь

Но вот юзать интерфейсы для связи с модулями/интеграции мастхев

ну это просто пример из опыта, от чего у нас попаболь

А ещё с чего?

А ещё с чего?

мертвый код, большая кодовая база.. ну это такое

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

Вот

У меня ща это. Два года назад плотно завязал проект на сервис рассылки мэилган, а теперь пытаюсь отвязать и сделать абстрактным все

Вот

Как называется этот паттерн что нельзя что-то напрямую пользовать, а только через прослойку?

Потому что возможен переезд на сендгрид или другой какой-то сервис

@za4me в Flysystem это называют адаптер: https://flysystem.thephpleague.com/core-concepts/

там идея в том, что есть разные хранилища файлов (aws, dropbox, in-memory) и чтобы отвязаться от конктретного хранилища юзают адаптер

там идея в том, что есть разные хранилища файлов (aws, dropbox, in-memory) и чтобы отвязаться от конктретного хранилища юзают адаптер

Также как например не используют напрямую MySQL, PostgreSQL, etc, а используют прослойку, которая для указанной БД в env отдаёт нужный класс с нюансами для определённой БД?

@za4me в Flysystem это называют адаптер: https://flysystem.thephpleague.com/core-concepts/

а разработчики ОС называют это драйвером виртуальной файловой системы)

но паттерн сам по себе называется адаптер)

думаю "инверсия зависимостей" лучше подходит, чем адаптер

думаю "инверсия зависимостей" лучше подходит, чем адаптер

нет

в контексте адаптеров

инверсия зависимостей это когда у тебя есть 2 модуля (не класса а именно модуля, компонента если хочешь). И у тебя один зависит от другого, но этот другой менее стабильным, потому ты делаешь в стабильном модуле интерфейсик, который четко дакларирует что тебе от другого модуля надо, и другой модуль его реализует. И теперь менее стабильный модуль зависит от более стабильного.

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

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

Хорошо, прослойка занимающаяся конвертацией - это адаптер. Но если мне просто хочется абстрагироваться от конкретного email транспорта с помощью interface EmailSender, то это ведь уже инверсия зависимостей, а не адаптер?

Хорошо, прослойка занимающаяся конвертацией - это адаптер. Но если мне просто хочется абстрагироваться от конкретного email транспорта с помощью interface EmailSender, то это ведь уже инверсия зависимостей, а не адаптер?

нет, это просто полиморфизм и абстракция

ERROR: S client not available

инверсия зависимостей - это когда у тебя интерфейс EmailSender принадлежит тому модулю, которому надо отправлять Email

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

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

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

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

но я все же думаю что это просто полиморфизм)

короч все на самом деле упирается тупо в направление зависимостей между модулями. Штуки которые меняются должны зависеть от штук которые меняются реже. Интерфейс меняется реже реализаций. Модули использующие твой EmailSender должны меняться чаще чем сам модуль содержащий этот интерфейс.

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

инверсия зависимостей - это когда у тебя интерфейс EmailSender принадлежит тому модулю, которому надо отправлять Email

Именно так ща у меня

по сути инверсия зависимостей это больше механизм нежели принцип. У дяди боба в былые дни было 11 принципов

один из них - принцип стабильных зависимостей

есть там еще принцип абстрактных зависимостей

вот они понятные)

а потом ему кто-то подсказал что из части его принципов получается OLID

и он добавил SRP и выкинул "лишнее"

@fes0r спасибо за ответы

а пробовал кто-нить че то такое https://www.npmjs.com/package/swagger-to-graphql

чтоб имея схему сделать такую прослойку

и не париться с graphql в пхп, интересно насколько оно может быть рабочим вариантом

Мне кажется всеравно будешь играться ограничивая сложность запроса/n+1 запросов . Не думаю что прослойка будет как-то умно все это делать

ну с промисами у ноды это наверно попроще будет

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

ну и кажется это возможность оставить пых с привычным хттп апи

Давали на выбор мне либо консольный калькулятор. Не справился и грустил. Сделал одним классом и регекспами

Им не понравилось

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

Мне ещё нравится усложненная версия, где нужно вводить абстракцию для дробей https://gist.github.com/codedokode/7005985

2.6.0 альфа xdebug вышел с поддержкой 7.2 пхп и профайлингом памяти

Привет всем.

Подскажите по фикстурам, в доке они на чистом PHP, но я ранее использовал nelmio/alice, что лучше?

Второй способ более приятен конечно как по мне.

я юзаю nelmio alice