Напрямую в сервисе инжектить другой сервис?

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

public function __construct(I\Want\This\Object $obj) {

Да это знаю.

В ларавел также

В чем вопрос тогда?

Видимо я неправильно понял и злом считается инъекция самого класса контейнера

С этим соглашусь

ну да, зачем тебе контейнер в сервисе? Тебе ж нужны другие сервисы из контейнера, а не сам контейнер

Вот у меня только одна беда. Был случай что в сервисе 3 репозитория и 3 сервиса иньектятся

Многовато

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

Видимо декомпозировать надо

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

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

Репозитории тоже иньектить?

Репозитории тоже иньектить?

канеш

иньектни entitymanager

твой код вообще не должен знать ничего о контейнерах

не иньекти энтити манагер

иньектни entitymanager

лучше репос

иньекти репозитории

достать инфу - тебе хватит репы

создать инфу = создать сущность, отдать наверх (в контроллер) и там persist/flush

тут репозиторий даже не нужен

Если 6 инъекций декомпозировать?

Сколько это норм

3?

если их больше 4х то уже стоит смотреть че так много

Ок

Ещё вопрос. В ларавел есть коллекции. В симфони только массивы?

ArrayCollection в доктрине

но лучше массивы юзай

У меня пока вообще нет бд. )))

Классы только

но лучше массивы юзай

А в чём беда с коллкцией от доктрины? Начал её юзать - вроде удобно

А в чём беда с коллкцией от доктрины? Начал её юзать - вроде удобно

в принципе нет бед, у нас их тоже много

главное iterable типы юзать в аргументах)

если тебе не надо функции типа contains, filter etc то массив

создать инфу = создать сущность, отдать наверх (в контроллер) и там persist/flush

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

ну началось)

ща батю позову он за всё расскажет

Сервисы это инфраструктура?

ну началось)

Таки да )

вобщем не работает не один вариант(( симфони смотрит только в двух директориях, app и vendor...twig

Доменная область это entity, vo, dto?

ух ща будет)

ща батю позову он за всё расскажет

Батю не Fesor случайно зовут?

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

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

Батю не Fesor случайно зовут?

шаришь

Сервисы это инфраструктура?

Инфраструктура - конкретные библиотеки, инструменты, фреймворки

шаришь

Он мне дал задание сделать клон убера

Вот делаю на симфони

Сервисы это инфраструктура?

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

Инфраструктура - конкретные библиотеки, инструменты, фреймворки

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

If you need to refer to a template that lives in a bundle, Symfony uses the Twig namespaced syntax (@BundleName/directory/filename.html.twig).

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

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

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

Ахаха

There are no registered paths for namespace "AppBundle".

это оч в идеальном мире

Доменная область это entity, vo, dto?

При ddd именно так, а ещё aggregates, repository Если использовать анемичную модель, то dao + services

There are no registered paths for namespace "AppBundle".

а с маленькой буквы попробуй все что после AppBundle написать

There are no registered paths for namespace "AppBundle".

в четверке нет AppBundle

в четверке нет AppBundle

3.4

а с маленькой буквы попробуй все что после AppBundle написать

тоже

При ddd именно так, а ещё aggregates, repository Если использовать анемичную модель, то dao + services

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

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

Чтобы не зависеть от конкретных технологий и решений Ты можешь писать приложение, не имея понятия какие бд или либы будут использоваться в конечном счёте, а при поддержке проекта ты сможешь жонглировать технологиями как захочешь, в зависимости от нагрузок

ERROR: S client not available

в конфиге не надо прописывать конфиг для твига?

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

NDA, могу только ссылок полезных дать

Интересно существует ли хоть один проект с вышеописанными правилами ?

"жонглировать технологиями" получается только в статьях/книжках, я серьезно.

Разве что у Эванса на компе

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

Жёстко просто не привязываться entity к orm, использовать адаптеры и мосты

адаптеры и мосты займут оч дофига времени

ахаха, на заводе все писалось в 94 году, никто не думал тогда, что БД можно менять, а была лицуха Оракла. Ну и писали через Оракловые коннектора. Щас этот оракл мозги трахает так, что мама не горюй! Но никуда не денешься с подводной лодки. Половина исходников потеряна, а в другую половину я даже суваться не стану

"жонглировать технологиями" получается только в статьях/книжках, я серьезно.

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

Чтобы не зависеть от конкретных технологий и решений Ты можешь писать приложение, не имея понятия какие бд или либы будут использоваться в конечном счёте, а при поддержке проекта ты сможешь жонглировать технологиями как захочешь, в зависимости от нагрузок

все изи бро

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

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

Как эластикsearch потом заменить на что то другое? Не привязываясь к нему

Как эластикsearch потом заменить на что то другое? Не привязываясь к нему

через адаптер жи

через адаптер жи

Как же все легко

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

а вот доктрину как выпилить - хз

Как эластикsearch потом заменить на что то другое? Не привязываясь к нему

Как раз недавно писал микросервис на джаве с использованием solr, выделил в один репозиторий работы с solr, а в другой elasticsearch

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

все адаптеры поддерживать

через адаптер жи

Если интерфейсы не совпадают , то конечно адаптер

это занимает много времени и не стоит того я думаю

Inversion of Control - сила

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

смотря че там

бесконечное время на разработку

Inversion of Control - сила

Обоснуй )))

бесконечное время на разработку

ну если оно такое есть то да

если какой-то query builder нужен, то далеко не уедешь

Хуяк и в продакшн сила

если какой-то query builder нужен, то далеко не уедешь

ну адаптер)))

это занимает много времени и не стоит того я думаю

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