Он автовайра один шаг к фасадам

абсолютно разные вещи

Разные

но шаг один

есть Spring IoC и Guice в джава мире, где тоже во главе угла стоит автовайринг. и живут же как-то

в том веке все писали на xml

Именно как-то

и больше не хотят вспоминать те времена

Джава не показатель

тем более спринг

:D

Джава не показатель

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

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

Знаю =)

https://www.reddit.com/r/PHP/comments/6oxuo3/what_do_you_thing_about_autowiring_in_symfony/dklnh2b/

For example, imagine you crafted a real nice service with a single implementation, that you need to inject somewhere. After a while, someone notices your service but creates an alternative implementation for some reason. By just declaring this new bean in the context, along with the former, it will break container initialization! Worse, it may be done in an entirely different part of the application, with seemingly no link with the former. At this point, good luck to analyze the reason of the bug.

Автовайр на практике хорош только для мелких проектов или отдельных Классов типа репозиториев

Но в кровавом энтерпрайзе это геморой

Это как мы пытались на phalcon писать энтерпрайз

а что мешает иметь автовайринг включенным по дефолту, но конфигурировать ручками то что нужно?

а что мешает иметь автовайринг включенным по дефолту, но конфигурировать ручками то что нужно?

отключенным ты хотел сказать?

ничего

так и нужно

а что мешает иметь автовайринг включенным по дефолту, но конфигурировать ручками то что нужно?

Слабо развитое чувство здравого смысла ))

Я курить

Слабо развитое чувство здравого смысла ))

+

Это как наркотик

тут аключил автовайр

А завтра и там включишь

и там

и там

и все

ты автовайр наркоша

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

в умелых руках и .. молоток =)

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

Исключительно из опта. Аргументы выше

For example, imagine you crafted a real nice service with a single implementation, that you need to inject somewhere. After a while, someone notices your service but creates an alternative implementation for some reason. By just declaring this new bean in the context, along with the former, it will break container initialization! Worse, it may be done in an entirely different part of the application, with seemingly no link with the former. At this point, good luck to analyze the reason of the bug.

Вполне аргумент

у нас опыт противоположный, размер кодовой базы 500к+ строк

Я вот послушался ваших советов, и решил перекинуть репозитерии в сервисы. Для этого, я: 1) Создал один интерфейс(CityRepositoryAwareInterface) и трейт(CityRepositoryAwareTrait), чтобы в нужном место просто подключить их и не дублировать. 2) В нужном контроллере подключил сервисы: services: ApiBundle\Controller\CityController: calls: - [ setCityRepository, ['@Klabs\Sale\CommonBundle\Aware\CityRepository\CityRepositoryInterface']] 3) Непосредственно указываю, что это данный рпеозиторий является сервисом: services: Klabs\Sale\CommonBundle\Aware\CityRepository\CityRepositoryInterface: class: Klabs\Sale\CommonBundle\Repository\CityRepository arguments: ["@doctrine.orm.entity_manager", '@metadata']

единственное чего не хватало так это иньекции коллекции по интерфейсу, но в 3.4 сделли иньекцию по тегу

Я вот послушался ваших советов, и решил перекинуть репозитерии в сервисы. Для этого, я: 1) Создал один интерфейс(CityRepositoryAwareInterface) и трейт(CityRepositoryAwareTrait), чтобы в нужном место просто подключить их и не дублировать. 2) В нужном контроллере подключил сервисы: services: ApiBundle\Controller\CityController: calls: - [ setCityRepository, ['@Klabs\Sale\CommonBundle\Aware\CityRepository\CityRepositoryInterface']] 3) Непосредственно указываю, что это данный рпеозиторий является сервисом: services: Klabs\Sale\CommonBundle\Aware\CityRepository\CityRepositoryInterface: class: Klabs\Sale\CommonBundle\Repository\CityRepository arguments: ["@doctrine.orm.entity_manager", '@metadata']

Репозитории да

Я вот послушался ваших советов, и решил перекинуть репозитерии в сервисы. Для этого, я: 1) Создал один интерфейс(CityRepositoryAwareInterface) и трейт(CityRepositoryAwareTrait), чтобы в нужном место просто подключить их и не дублировать. 2) В нужном контроллере подключил сервисы: services: ApiBundle\Controller\CityController: calls: - [ setCityRepository, ['@Klabs\Sale\CommonBundle\Aware\CityRepository\CityRepositoryInterface']] 3) Непосредственно указываю, что это данный рпеозиторий является сервисом: services: Klabs\Sale\CommonBundle\Aware\CityRepository\CityRepositoryInterface: class: Klabs\Sale\CommonBundle\Repository\CityRepository arguments: ["@doctrine.orm.entity_manager", '@metadata']

Но вот проблема в том, что Entityrepository в качестве аргумента использует некий класс Doctrine\ORM\Mapping\ClassMetadata

а зачем CityRepositoryAwareTrait?

А не знаю, что это за класс?

а зачем CityRepositoryAwareTrait?

Чтобы в нужном месте просто вставить этот трейт и обращаться к его свойству

Чтобы в нужном месте просто вставить этот трейт и обращаться к его свойству

не лучшая затея. в конструкторе укажи просто CityRepositoryInterface , без всяки трейтов и сеттеров

Читал, что трейты в PHP - зло, так как не являются чистыми mixin-ами, а являются костылями для кривокруких

Аргументы, правда, не помню

не лучшая затея. в конструкторе укажи просто CityRepositoryInterface , без всяки трейтов и сеттеров

Я просто хз, насколько оно разрастется(конструктор)

?

Так что автовайр - добро или зло?

не лучшая затея. в конструкторе укажи просто CityRepositoryInterface , без всяки трейтов и сеттеров

Для меня легче, чтобы все это хранилось отдельно в конфиге. А в классах смотреть только непосредственно сами методы и реализация

Я просто хз, насколько оно разрастется(конструктор)

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

Вопрос в том, что как узнать название сервиса по класссу? (Doctrine\ORM\Mapping\ClassMetadata)

нужен бот для голосования

Читал, что трейты в PHP - зло, так как не являются чистыми mixin-ами, а являются костылями для кривокруких

я трейты только для LoggerAware юзаю

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

Контроллер?

Autowiring это... Добро – 60 ??????? 92% Зло – 5 ? 8% ? 65 people voted so far.

Вопрос в том, что как узнать название сервиса по класссу? (Doctrine\ORM\Mapping\ClassMetadata)

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

Контроллер?

да, а чего бы и нет

да, а чего бы и нет

Просто я и так стараюсь чтобы контроллер был "тонким", куда еще хз.

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

Это как?

Это как?

выше было

ERROR: S client not available

но у нас немного проще AppBundle\Repository\Users: factory: ["@doctrine.orm.entity_manager", getRepository] arguments: [AppBundle\Entity\User]

Вот я так понимаю

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

пс. сорян что с нотифаем

не, норм

Читал, что трейты в PHP - зло, так как не являются чистыми mixin-ами, а являются костылями для кривокруких

главный косяк трейтов, который обнаружил - это то, что они, по сути - это тупо внутренний копипаст

Да ну! В телеграмме есть возможность голосования?

через ботов)

Да ну! В телеграмме есть возможность голосования?

боты

Я еще дикий - месяц пользуюсь

в телеграме есть все через ботов

Чьёрд! Да это же викторину можно устроить и призы победившим, систему прокачки- ветераны, новички

На средне/малых проектах автовайринг однозначо добро. Но на больших проектах имхо его полезность сомнительна. Я за явный конфиг.

Better practice? That will not last for long. We always lag the Java community by a few years, so now as autowiring is becoming hot in PHP, the Java community has been burned by the resulting dependency spaghetti are calling it an anti-pattern. It's a very tiresome cycle: "best silver bullet ever!" and then "worst anti-pattern ever!". I'm not saying "do not use autowiring at all" (although I do not), but stay conservative and never ever allow your code to be dictated by the autowiring features. Never change how you design an object because of autowiring. And I'm afraid this is easier said.

На средне/малых проектах автовайринг однозначо добро. Но на больших проектах имхо его полезность сомнительна. Я за явный конфиг.

Я о том же и говорил

Хм, transactional() очень удобное место. Если ошибка вылетает, то и флаш не юзается. @fes0r А если надо выполнить отправку письма юзеру после успешного сохранения, вы заворачиваете флаш в try - catch, и отсылаете письмо после флаша сразу, моя логика верна?

у меня это на доменных ивентах, которые файрятся ТОЛЬКО если у тебя все было хорошо

Чьёрд! Да это же викторину можно устроить и призы победившим, систему прокачки- ветераны, новички

на конференциях так делают.

Better practice? That will not last for long. We always lag the Java community by a few years, so now as autowiring is becoming hot in PHP, the Java community has been burned by the resulting dependency spaghetti are calling it an anti-pattern. It's a very tiresome cycle: "best silver bullet ever!" and then "worst anti-pattern ever!". I'm not saying "do not use autowiring at all" (although I do not), but stay conservative and never ever allow your code to be dictated by the autowiring features. Never change how you design an object because of autowiring. And I'm afraid this is easier said.

там где автовайринг не подходит, есть php dsl с 3.4 версии

Кажется я открыл для себя нищщу для игроделов - текстовые квесты в телеграмме

главный косяк трейтов, который обнаружил - это то, что они, по сути - это тупо внутренний копипаст

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

Autowiring это штука более для автоматизации чем для надежности

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

если честно - я твой случай не увидел :) увидел "трейт" - сказал свое слово :) сейчас посмотрю

Autowiring это штука более для автоматизации чем для надежности

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

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

автовайр это не про гибкость

А про простоту

Ну и он более медленный

Так как использует рефлексию

Ну и он более медленный

ноу

более медленный - на этапе сборки контейнера

конечный контейнер одинаковый выходит

Ну тут спорить не буду

а сборка медленнее на 20-30% это да

Так как использует рефлексию

А конфиги как буд то проще читать, чем классы ))