Или берешь друпал )

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

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

А вот честно - хз: 1) Так будут цикличные зависиомсти на изи 2) Как тогда работать если нет "сервисов" таких больших? Делать сервис с 1 методом выборки, который дергает репохиторий? Сервис чисто для прослойки к репо? хз.

Так сервис для прослойки к репо делается что бы зависимости не протекали на слой ниже? (Я ещё балбес в этом))

И от меня вопрос, здратути)) Кто как мапит управление one -to -many связями? Кейс: с фронта прилетает колллекция, которую надо установить в сущность: [{id:1, name: "for change"}, {id: null, name:"for insert"}] и еще надо удалить будет c id =3, потому что она сейчас есть, а запросе как видим нет. Собственно возникают вопросы: 1) Где лучше сделать логику какую сущность изменить, какую удалить, какую добавить? 2) Что вообще должно прилетать в главную сущность (в которой хранится коллекция), какая то DTO (которая не улетает в БД) или сами сущности? Но как тогда например управлять удалением и добавлением(ведь id то нет). В application слое?

Я свой гист кидать не буду уже а то захейтили

Репозиторий и так сервис

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

Тут где-то обсуждалось что типо можно разделит еще по принципу если это простой запрос через dql, то это репозиторий, если сложный резалт сет мапиинг то это DataSource

Как это вообще к вопросу относится, какая реализаци внутри репо?

Мы меняем репо реализацию на репо с апи внешнего сервиса вместо бд и не трогаем сервис. Но вообще хз, я вообще битриксоид 😂 там ни то, ни то не принято.

В общем меня в двух местах учили разделять на репо и сервис. Деталей уже не расскажу зачем именно.

Разделить то понятно надо (персистенс от логики), но зачем дергать в сервисе репо через другой сервис - не понятно

понапридумывают себе проблем. Слоев каких-то. Писали бы все в контроллерах - не было бы проблем))

понапридумывают себе проблем. Слоев каких-то. Писали бы все в контроллерах - не было бы проблем))

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

писать "надо" согласно бюджету и предполагаемых масштабов проекта)

Спасибо, я так в битрикс попал 😂 Год уже вырваться от него пытаюсь.

Спасибо, я так в битрикс попал 😂 Год уже вырваться от него пытаюсь.

Кстати, а кто что скажет за https://github.com/symfony/demo код нормальный? как пример "как надо писать" брать можно?

битрикс не так уж и плох в определенном спектре задач)

битрикс не так уж и плох в определенном спектре задач)

экспорт в 1с? )

экспорт в 1с? )

на чем вы быстрее напишете интернет-магазин для местного магазинчика с одной единственной точкой?

вот именно.

Он из коробки почти никогда не работает. 😂😂😂 Потому что 1С не такая

Но с другой стороны там 10 шапок сухарей почти никак бюджета не получить. А про масло и свежий хлеб можно и не вспоминать)

Ты што! Там же полная интеграция с 1с из коробки!! 1

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

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

Ага, как весной, когда почти всех поломали, кто не обновлен был?) Жаркая неделька была у меня всем сайты восстанавливать.

нет, там нюансы с партнерской скидкой и перепродажей лицензий же

а так интересно, что поломали) У нас из ~60 клиентов пали смертью храбрых только двое. И с битриксом проблемы не были связаны

ядро было времен динозавров что ли?

ядро было времен динозавров что ли?