@iSize1ce у нас такая же херня. Своё MVC-шное «ядро», шаблонизатор (типа Twig) ставить нельзя (ТОРМОЗИТ!!!111), нормальную абстракцию от БД нельзя (есть своя даже с «репозиториями», которые долбятся в базу и пришиты к MySQL, но сырые запросы наше всё, всё остальное тормозит и НИНУЖНО, а еще места много занимает, да, а делает много ненужной херни). ???

Звучит как арх из 90х

@iSize1ce у нас такая же херня. Своё MVC-шное «ядро», шаблонизатор (типа Twig) ставить нельзя (ТОРМОЗИТ!!!111), нормальную абстракцию от БД нельзя (есть своя даже с «репозиториями», которые долбятся в базу и пришиты к MySQL, но сырые запросы наше всё, всё остальное тормозит и НИНУЖНО, а еще места много занимает, да, а делает много ненужной херни). ???

Я работал в таком месте, весело ?

А, еще DI-контейнера нет.

Сразу через синглтоны?)

наследование и трейты поди )

@alfabind в том числе.

И тестов нет?

Только на одном из подпроектов, насколько я знаю.

Бинго! Та самая контора, которую я избегаю всю сознательную жизнь

Ну, моё присутствие «здесь» не вечно =)

Спрашивай как часто деплоятся

Выявление половины симптомов сразу

как в сервисах юзать em? В services.yml churn_kpi: class: VC\ChurnBundle\Services\Kpi arguments: entityManager: [ "@doctrine.orm.entity_manager" ] ругается на строку public function __construct(EntityManager $entityManager) Type error: Argument 1 passed to VC\ChurnBundle\Services\Kpi::__construct() must be an instance of Doctrine\ORM\EntityManager, array given, protected $em; public function __construct(EntityManager $entityManager) { $this->em = $entityManager; }

Ентити менеджер в сервис

Звучит как god class

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

как в сервисах юзать em? В services.yml churn_kpi: class: VC\ChurnBundle\Services\Kpi arguments: entityManager: [ "@doctrine.orm.entity_manager" ] ругается на строку public function __construct(EntityManager $entityManager) Type error: Argument 1 passed to VC\ChurnBundle\Services\Kpi::__construct() must be an instance of Doctrine\ORM\EntityManager, array given, protected $em; public function __construct(EntityManager $entityManager) { $this->em = $entityManager; }

А у тебя переносы не напутаны?

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

Неправда. Если надо что-то создать, то как иначе?

Через репу

Это ответственность персиста

Но симфони все стерпит да

Репа не должна сохранять. Она должна доставать.

Репы - это хранилище.

Юзаю денормолайзер в сайлексе. Обьект без методов, все на публичных свойствах. Передаю валидный массив. В любом случае выдается ошибка "Could not denormalize object of type AccountBundle\\Entity\\Account\\Account, no supporting normalizer found."

В чем проблема?

Кто-нибудь сталкивался, может

ObjectNormalizer подключаю

Чтобы не разрастались сервисы, надо именовать их не сервисами а вполне конкретными названиями. PortalDataFetcher или NewsUpdater

Без приставки Service

хорошо, хорошо, делайте как вам нравится

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

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

Ну а почему тогда именования методов должны начинаться на find?

у репозитория?

Не проблематичнее чем репы.

Ага.

ну почитайте официальную документацию

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

You can think of a repository as a PHP class whose only job is to help you fetch entities of a certain class.

Как раз таки юзать репы для всего - это против Single Responsibility.

https://martinfowler.com/eaaCatalog/repository.html

посмотри на репы в ДДД

там и find и save

но никто не мешает юзать CQRS

когда у тебя отдельно чтение и отдельно запись

CQRS немного идиотическая идея

много саппорта из-за малого профита

ну чувак же не хочет в репу сохранение встраивать

ну потом ему скажут спасибо, ища по всему проекту функциональность

а не найдя - впилить свое

обычно непрозрачное поведение находит свои велосипеды

Ок. А где ты используешь энтити мнеджер?

напрямую только в репозитории

ну и в бехате на старте для чистки базы

Ок.

сервис общается с сервисом через экспозируемые методы

оно хорошо скейлится

Не лучше чем репы

Измени сигнатуру метода.

это контракт

И будешь так же рефакторинг везде.

если ты меняешь контракт, значит ты что-то делаешь не так

Это контракт только пока новые требования не подвезли.

можешь сделать фасад перед сервисом

Ты идеализируешь разработку.

обычно новые изменения не трогают так сильно ключевые понятия системы

ERROR: S client not available

Ой не надо.

Ещё как трогают.

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

Выявление половины симптомов сразу

как именно?)

Ну ты моего говна не видел. И проекты мои не видел.

есть четко выделенные контексты взаимодействия

Откуда столько экспертности?

друг, я с тобой не спорю

просто не переноси свой опыт на меня

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

Ты утвер

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

есть код, есть спеки, есть юнит на определенные моменты

это пример, метафора

Ок.

Метафора под собой вполне конкретные утверждения подразумевает.

давай тему сменим

я не вижу конструктива

просто аккуратней с выражениями надо быть чтобы не агрить потом на себя )

У меня тоже нет рывков в разработке. Но когда стейкхолдер приходит и говорит, ребята, надо вот такую фиск реализовать. Ты не говоришь ему "ну нееее. У нас там репозитории. Контракты. Не получится".

Ты делаешь.

бизнесу про техчасть?

говно оно у всех разное и пахнет со временем тоже по-разному

серьезно?

я бы посмотрел

Ок. Пм приходит.

Не буквоедствуй

а почему не получится?

ПМ обычно понимает за техдолг

почему такой ответ?

Ну по словам Андрея.

У него идеальный мир книжный в программировании.