Да и для крупных тоже )

Последние 2 проекта имели 10 летнюю историю. Очень хотелось убить всех любителей попроще.

Ты считаешь, нужно всегда делать сложно?

Делать надо так чтобы легко читалось, легко тестировалось, легко рефакторилось

Для этого должна быть возможность следовать срп принципу. Как ты разделишь ентити?

Нужно понимать этот принцип

Я yii и других похожиш есть понятие модель

Если ты будешь всю логику писать в ентитях у тебя не получится разделить ее

Замени слово модель на сервис и все встанет на свои места

Писать всю логику это ваши слова. Не стоит их мне приписывать

Только к симфони это не имеет никаклго отношения

Писать всю логику это ваши слова. Не стоит их мне приписывать

У заказа есть товары, есть расчет скидки, расчет доставки и т.д. Это все должны быть разные классы.

Конечно. Есть такое понятие как агрегат. Заказ частично будет оперировать несамостоятельными сущности

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

Но это нарушение срп

Нет.

Где тут по доктрину?

Как нет. У тебя один агрегат выполняет разные операции

Ну ентити доктрины должны быть у тебя как структуры

Агрегат реализующий бизнес логику заказа должен всегда нести эту логику. Нарушение SRP это если эта сущность делает что то ещё кроме работы с заказом

Изменения должны быть в одно время и по одной причине. Доставка, скидка и т.д. это разные причины для изменения.

Доставка заказа это не Заказ. Скидка это часть Товара.

Ну вот, видишь, метод Применить скидку к заказу. Тогда норм

И у тебя будет огромный объект заказа, выполняющий кучу разных функций.

У меня нет. У вас возможно. Не я же доставку сущности хотел внутрь засунуть

С кучей завистмостей и без контейнера

Ну а как ты сделаешь? order->calculateDiscount()

Потом order->calculateDelivery

Зачем формы для рест?

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

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

затратно в написании всяческихлисенеров и субскрайберов

Подскажите, пожалуйста: Использую lexikjwt для аутентификации, и аутентифицирую по полю email, но мне не нравится, что клиент будет указывать в запросе username, а не email. Можно ли как то сменить имя поля в json-e?

https://symfony.com/doc/current/security/json_login_setup.html

Подскажите, пожалуйста: Использую lexikjwt для аутентификации, и аутентифицирую по полю email, но мне не нравится, что клиент будет указывать в запросе username, а не email. Можно ли как то сменить имя поля в json-e?

у него JWT)

И что? Получает то он его через json_login вероятно

https://symfony.com/doc/current/security/json_login_setup.html

А для чего там лисенеры

Пока пример сложно придумать) ну из актуалочки все ещё не найду валидатор по вложенной сущности, существует ли такая

Всем привет. Возвращаясь к вчерашнему разговору. Вот пример есть) Есть сущность, назовём её Item. Она может быть разных типов: SimpleItem, PollItem, SubscriptionItem... Надо понять, может ли юзер активировать эту сущность. При этом у каждого типа там могут быть свои условия. Раньше в каждом классе сущности был метод canBeActivated(User $user). И для каждого он реализовывался по-своему. Но это очевидно неправильный подход, т.к. условия там могут зависить от внешних данных и даже возможно сервисов. Вопрос - куда лучше поместить этот метод? Для каждого типа айтема написать свой сервис активации и там и проверять условия? или как?

AuthorizationChecker же