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

А это разве не Controller as a service?

в формах вроде как рекомендуют в data_class ложить не сущность, а dto, либо же в симфе есть трансформер из формы в сущность и обратно

А чем сущность отличается от ДТО?

А это разве не Controller as a service?

он самый, только продвинутая версия. изначально было когда регаешь контроллер как сервис, то прощаешься со всеми плюшками типа $this->render, а теперь сделали более хитрый способ

https://stovepipe.systems/post/avoiding-entities-in-forms по поводу форм и сущностей

он самый, только продвинутая версия. изначально было когда регаешь контроллер как сервис, то прощаешься со всеми плюшками типа $this->render, а теперь сделали более хитрый способ

Аааа. Неплохо :)

Но вообще там комменты весьма разные :)

Но я так понял, этот способ не отменяет стандартный метод.

стандартный метод уже немного устарел

https://github.com/symfony/symfony-standard/blob/3.3/src/AppBundle/Controller/DefaultController.php тут уже AbstractController идет к примеру

https://github.com/symfony/symfony-standard/blob/3.3/app/config/services.yml#L27 и вот регают контроллеры

ну мне кажется и у того и другого способа есть и плюсы и минусы.

у привычного способа слишком много минусов

я на каждый интеграционный тест, использующий БД, гружу фикстурки. Сейчас подумал, а можно ли запускать тест в транзакции и откатывать её после теста? это нормально?

да, на эту тему докладов и статей много было

Многие так делают.

@Enleur спасибо, как раз хотел найти эту статью) пора в закладки положить.

@Gaaarfild DTO — это просто структура данных. Без логики.

Как и сущность должна быть такой же

В правильной сущности не должно быть логики

Единственное, чем она может отличаться - аннотациями для доктрины. Но без доктрины аннотации - просто комментарии.

И это просто ДТО.

В правильной сущности не должно быть логики

ого

Я не прав? :)

В правильной сущности не должно быть логики

наоборот же

Ну максимум логика может бысть связана только со своими данными.

И тогда это наверно уже не сущность а модель.

Простейшам логика типа isActive там или еще че нить.

логика должна быть, но логика поведения самого объекта

Понятно. А где можно прочитать про это?

Понятно. А где можно прочитать про это?

https://martinfowler.com/bliki/AnemicDomainModel.html

https://github.com/symfony/symfony/pull/23315 неужели

я на каждый интеграционный тест, использующий БД, гружу фикстурки. Сейчас подумал, а можно ли запускать тест в транзакции и откатывать её после теста? это нормально?

для phpunit есть https://packagist.org/packages/dama/doctrine-test-bundle

для phpunit есть https://packagist.org/packages/dama/doctrine-test-bundle

а еще есть codeception :)

с регистрацией контроллеров в контейнере

Ты имеешь ввиду AppBundle\Controller\: resource: '%kernel.project_dir%/src/Controller' public: true tags: ['controller.service_arguments'] ??

а еще есть codeception :)

есть, но если у тебя тесты в behat/codeception гоняются через вебсервер, то ролбэк сделать не получится.

если использовать kernel driver, то можно переиспользовать StaticDriver, который в этом бандле есть

так через кодсепшн можно ж и юнит писать

так через кодсепшн можно ж и юнит писать

можно, но для юнит-тестов и роллбеки не нужны

как и бд

для phpunit есть https://packagist.org/packages/dama/doctrine-test-bundle

благодарю

Всем привет, проблема с JMSSerializer. Пытаюсь сериализовать массив обьектов Group. У обьекта Group есть свойство типа Course. Файл Entity.Group.yml примерно такой: AppBundle\Entity\Group: exclusion_policy: ALL properties: id: expose: true groups: [default] description: expose: true groups: [default] course: type: AppBundle\Entity\Course expose: true groups: [default] Есть также файлик Entity.Cource.yml, там expose для примитывных типов. На выходе чтото топо того (поле course сериализовалось как пустой объект): [{ "id": 1, "description": "test", "course": {} },...] Кто-то сталкивался с подобным? UPD: Отдельно объект Cource нормально сериализует.

для phpunit есть https://packagist.org/packages/dama/doctrine-test-bundle

Это мой CTO :)

А есть ли тут немного фронтедные опытные чуваки? :)

Подскажите, почему Бабель косячит. Если в функции где-то аргументом встречается null, то он дальше этот файл не обрабатывает, а подключает следующий. Из-за этого естественно ошибка на странице. Код транспайленный выглядит вот так swal(Translator.trans('package_modal_error'), "use strict"; Хотя должен был вот так swal(Translator.trans('package_modal_error'), null, 'error'); use strict это уже начало другого файла Если заменяю null на пустую строку, то нормально идет.

эм

вряд ли это бабель виноват

нашел проблему.

Это генерация соурс мапа из вывода бабеля, но до аглифая.

Сейчас сделал ее до бабеля, и заработало

Как лучше всего тестировать логику, которая стучится в АПИ и данные оттуда достаёт и записывает в БД. А другой роут отображает в нужном формате.

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

Как лучше всего тестировать логику, которая стучится в АПИ и данные оттуда достаёт и записывает в БД. А другой роут отображает в нужном формате.

ну эт 2 разные логики

Ну вот как их тестировать?

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

Чтобы он при этом и сломался, если апи поменяется. Каждый раз дергать?

ну ты тестируешь не их апи же, а свой код

если тебе нужно детектить то что у них апи сломалось это уже отдельная тема

Но мой код должен мне подсказать же, если он больше не может с их апихой работать?

Это же мне фиксить придётся.

Вроде как нет как раз, это херовая апиха, если обратная совместимость ломается

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

Ну по сути - да.

Ну а если она херовая? :)))

Вот мучаюсь выбором. :)

ERROR: S client not available

И ещё если обращения к апихе дорогие.

То есть часто делать - не айс.

А какой смысл в тесте это делать? Тесты допустим срабатывают на сборке билда, чтобы на прод не выгрузилось говно Если апи отваливается и тест проверяет её наживую, конечно он тебе скажет, что все херово, но как тебя это спасет? Сломалось чужое апи - сломался и продакшн билд

Может кешировать в моки?

Тоже верно.

Но прод может продолжать работать, так как сломался только пишущая логика.

В общем, я в целом понял.

Спасибо. :)

А вот кстати SOA, я не знаю всех минусов и сложностей Но недавно смотрел опыт работы с ним в hh Дошел до хорошего плюса - отказоустойчивость, т.е. например фронт стучит куда-то и если тот или иной сервис не отвечает, не весь сайт ломается, а только лишь раздел

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

Потом очень просто отдать тот или иной функционал на аутсорсинг

SOA как панацея ненене, но все равно интересная же тема достаточно

даже без соа как часто у тебя ломается весь сайт из-за ошибки в каком-то из модулей?

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

даже без соа как часто у тебя ломается весь сайт из-за ошибки в каком-то из модулей?

Не, ну а если что-то глобальное? Бд повалилась или еще чего..

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

Inheritance Mapping?

да

Сергей, используем. Проблем нет, по крайней мере с Single Table.

К недостаткам можно отнести то, что структура таблицы становится менее очевидной.

А насколько это важно кстати?

Зависит от обстоятельств, но в моей практике два-три nullable поля допускаю

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

Кто-то еще напрямую с базой работает?!

Ну это херовый подход был бы

Работают некоторые. В devzen ведущий рассказывал, что ему мешаются все эти ORM, проще и быстрее сразу SQL написать.

Перечитал, не совсем ясно выразился: можно и в рамках ORM на грабли наступить с неправильной схемой, если конструировать там сложные запросы, выходя за рамки стандартного persist/findBy/flush. И чем больше полей и чем менее очевидна схема, тем проще это сделать.

Кстати, RSM не будет разруливать DiscriminatorMap?

А вот кстати SOA, я не знаю всех минусов и сложностей Но недавно смотрел опыт работы с ним в hh Дошел до хорошего плюса - отказоустойчивость, т.е. например фронт стучит куда-то и если тот или иной сервис не отвечает, не весь сайт ломается, а только лишь раздел

Это только в том случае, если у тебя бэк не монолитный. В противном случае, разницы нет в надежности. Так же могут просто сломаться определенные роуты. И будет работать пол сайта.

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

А вот кстати SOA, я не знаю всех минусов и сложностей Но недавно смотрел опыт работы с ним в hh Дошел до хорошего плюса - отказоустойчивость, т.е. например фронт стучит куда-то и если тот или иной сервис не отвечает, не весь сайт ломается, а только лишь раздел

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

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

опять же это не относится к SOA. Ты можешь пилить монолитные приложения как апихи и делать просто мидлвари или SPA

А плюсы есть?