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

Поэтому я всегда рекомендую лара-программистам оставаться на ларке. Мир симфони жесток и беспощаден (если не знать про php конфиги)

Поэтому я всегда рекомендую лара-программистам оставаться на ларке. Мир симфони жесток и беспощаден (если не знать про php конфиги)

а можете сказать про скрин выше еще?)

Я щас не хочу вдумываться, я один раз настроил и забыл

^_^

да, причём с отключением сессий

да, причём с отключением сессий

а как добавить метод в исключение

например api/login

добавить туда исключение для этого роута

вот например надо юзера забанить

Jwt Токен имеет небольшое время жизни, просто не продлевай его. Или заведи блеклист на время жизни токена если очень надо

добавить туда исключение для этого роута

туда эту куда?

у меня щас вот так вышло

хотя наверно это внутри меййна должно быть

Unrecognized option "guard" under "security.firewalls.api". Available options are "access_denied_handler", "access_denied_url", "access_token", "context", "custom_authenticators", "entry_point", "form_login", "form_login_ldap", "host", "http_basic", "http_basic_ldap", "json_login", "json_login_ldap", "jwt", "lazy", "login_link", "login_throttling", "logout", "methods", "pattern", "provider", "remember_me", "remote_user", "request_matcher", "required_badges", "security", "stateless", "switch_user", "user_checker", "x509".

вот такую поймал ошибку после добавления протекста атворизацией api

разобрался

уважаемые эксперты, я правильно понял что вся валиадция у нас в entity

ну т.е. по факту в модели

этоже в модель все кладется?

Нет. Валидация входящих данных происходит где-то на уровне контроллера. Проверка бизнес правил - в сущностях и доменных сервисах

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

тоже самое сказал чат jpt

ну понятно что сама валидация в контроллере

но метод валидации

он же в каком то классе создан

и вот вопрос в каком

а в контролере мы просто вызываем готовый метод и пихаем туда данные

С formBuilder я почти не работал, не подскажу. Я делал по другому. У каждого эндпоинта была своя dto запроса. Она исполняла интерфейс, который гарантировал 2 метода . 1 - map request, 2 - get constraints Перед тем как засунуть эту дто в аргумент контроллера, симфа вызывала params resolver который сначала вызывал 2 метод и валилировал данные, а потом мапил запрос при помощи первого метода. Как итог - контроллер получает правильную, собранную дто запроса. Сама валидация шла так https://symfony.com/doc/current/validation/raw_values.html

Как остальной мир валидирует, хз

этоже в модель все кладется?

По разному. Опять же это формы. Форма может использоваться для валидации. И это не обязательно сущность должна передаваться в неё. Правила можно класть как в форму, так и в сам объект через атрибуты над пропертями. Плюсы класть контсрейнты в форму - она вроде как валидирует не объект, а именно массив данных, который ей передали. А уже потом мапит на объект, а не наоборот, как mapPayload

Но в целом форма уже неактуальный вариант для апи, а вот где надо рендерить html - вполне

С formBuilder я почти не работал, не подскажу. Я делал по другому. У каждого эндпоинта была своя dto запроса. Она исполняла интерфейс, который гарантировал 2 метода . 1 - map request, 2 - get constraints Перед тем как засунуть эту дто в аргумент контроллера, симфа вызывала params resolver который сначала вызывал 2 метод и валилировал данные, а потом мапил запрос при помощи первого метода. Как итог - контроллер получает правильную, собранную дто запроса. Сама валидация шла так https://symfony.com/doc/current/validation/raw_values.html

Интересный вариант с getConstraints )

Но в целом форма уже неактуальный вариант для апи, а вот где надо рендерить html - вполне

В целом форма это для чего то простого, когда что то сложнее, то начинаются танцы с бубнами

В целом форма это для чего то простого, когда что то сложнее, то начинаются танцы с бубнами

Ну да, если не уметь в них играть

С formBuilder я почти не работал, не подскажу. Я делал по другому. У каждого эндпоинта была своя dto запроса. Она исполняла интерфейс, который гарантировал 2 метода . 1 - map request, 2 - get constraints Перед тем как засунуть эту дто в аргумент контроллера, симфа вызывала params resolver который сначала вызывал 2 метод и валилировал данные, а потом мапил запрос при помощи первого метода. Как итог - контроллер получает правильную, собранную дто запроса. Сама валидация шла так https://symfony.com/doc/current/validation/raw_values.html

У меня также но своеобразно, у меня вместо симфони slimphp у меня вместо контроллеров экшены на каждое действие, Actions\User\Add, Action\User\Delete внутри каждого такого экшена есть RequestDTO.php, Validator.php (валидирует и собирает dto), Service.php (использует дто из параметра), Action.php (передает сухие данные на валидатор и получает дто, дальше передает дто на сервис)

Как считаете нормальный вариант или нет

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

По итогу валидация у меня у каждого экшена где передаются данные

Я хотел подучить ddd, даже купил книжку прочитал одну главу и она все еще лежит), надо снова попробовать начать, а так для не больших проектах думаю обходиться без ддд

Как считаете нормальный вариант или нет

Да в целом ок, главное чтобы логика работы с пользователем не была завязана в контроллере Так как само действие не должно знать, как и где вызывается Ну и внутри самого действия должна быть описана только бизнес логика Если не прав, поправьте)

Да в целом ок, главное чтобы логика работы с пользователем не была завязана в контроллере Так как само действие не должно знать, как и где вызывается Ну и внутри самого действия должна быть описана только бизнес логика Если не прав, поправьте)

Внутри service.php экшена я создаю набор entity которые мне нужны через doctrine orm, эту логику думаете вынести в сервис?

Сам persist flush дальше заливает в бд и я возвращаю ответ

Я хотел подучить ddd, даже купил книжку прочитал одну главу и она все еще лежит), надо снова попробовать начать, а так для не больших проектах думаю обходиться без ддд

Ддд не про код

Ддд не про код

Это я понял

Вообще я бы попилил service, на отдельные классы /Services/User/UseCases/Add /Services/User/UseCases/Delete Логичный вопрос зачем выносить в класс - легче распределять зависимости для каждого действия

Вообще я бы попилил service, на отдельные классы /Services/User/UseCases/Add /Services/User/UseCases/Delete Логичный вопрос зачем выносить в класс - легче распределять зависимости для каждого действия

это называется аппликейшн слой)

и там не сервисы, а фичи

которые сервисы

и там не сервисы, а фичи

Ну я их тут юзкейсами обозвал, идея разбить логику А сам сервис получается как набор фич

ну или юз кейсы, да

вроде так даже правильнее

Вообще я бы попилил service, на отдельные классы /Services/User/UseCases/Add /Services/User/UseCases/Delete Логичный вопрос зачем выносить в класс - легче распределять зависимости для каждого действия

Вы клоните к тому чтобы я внутри напрямую не создал внутри \Actions\User\Add\Service.php а вынес в use cases и принимал этот класс внутри и через него создавал чтобы не делать persist flush?

Application\UserCreation\UserCreator.php

Вы клоните к тому чтобы я внутри напрямую не создал внутри \Actions\User\Add\Service.php а вынес в use cases и принимал этот класс внутри и через него создавал чтобы не делать persist flush?

Ну если закапываться) То вся работы с доктриной должна тоже в другой слой улететь) А если лень, то можно и там

а персист + флуш допустим вполне для апп сервисов

это в доменных нельзя

Если кратко, 1. Желательно разбирать каждое действие и не создавать один файл Service, а создать под каждое действие класс (UseCase) 2. В самом юзкейсе, должна быть только бизнес лооика логика (без завязок на внешние зависимости, такие как библиотеки, бд и т.п), которая принимает дтошку и обрабатывает 3. Сам юзкейс (так как это сугубо бизнес логика), не должен знать где что и как хранится, поэтому нужен класс прослойка Storage или т.п и уже в этой прослойке у тебя будет работа с бд Если не прав, поправьте, так как ещё сам постигаю

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

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

ну так юзкейс аггрегирует доменные сервисы

и реализует воркфлоу

так что это вполне себе бизнес логика

так что это вполне себе бизнес логика

Логика приложения, не бизнеса

ну так юзкейс аггрегирует доменные сервисы

В некоторых подходах доменных сервисов вообще не должно быть

В некоторых подходах доменных сервисов вообще не должно быть

это почему это?

flush в контроллере вызывать или в репозитории

и что это за подходы такие, где в домене нет доменной логики?

это почему это?

Потому что в сущности вся логика доменная

Потому что в сущности вся логика доменная

не, божественные сущности - это антипаттерн

это при только когда начинаешь возиться кажется что так надо

а потом начинаешь понимать, что чем сложнее всего - тем больше энтитя и больше в ней говна

а потом начинаешь понимать, что чем сложнее всего - тем больше энтитя и больше в ней говна

Делить можно если что

поэтому энтитю стоит всё же воспринимать как аггрегат и чем анемичнее оно тем лучше

ессесно с контролем состояния/инваривантов

Делить можно если что

на сервисы)

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

UC лежит в слое приложения и свободно может дёргать и домен и инфру. Можно через DepInv абстрагировать дёрганье инфры, но это дрочь

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

ну всё же в 2к24ом геттеры и сеттеры не особо актуальны

но так да, это самый оптимальный вариант