AK
Size: a a a
2021 March 21
DT
Возможно я предложу глупый вариант, но может проще написать voter, который будет управлять доступами по динамической иерархии ролей, как написал Макси. Проще динамического конфига
ПГ
Возможно я предложу глупый вариант, но может проще написать voter, который будет управлять доступами по динамической иерархии ролей, как написал Макси. Проще динамического конфига
Это не глупый вариант :)
ИЛ
Возможно я предложу глупый вариант, но может проще написать voter, который будет управлять доступами по динамической иерархии ролей, как написал Макси. Проще динамического конфига
можно свой атрибут написать и в сабскрайбере его чекать
проверка прав доступа - это всё же металогика, а не логика контроллера
проверка прав доступа - это всё же металогика, а не логика контроллера
k
можно свой атрибут написать и в сабскрайбере его чекать
проверка прав доступа - это всё же металогика, а не логика контроллера
проверка прав доступа - это всё же металогика, а не логика контроллера
чем "металогика" отличается от "логики контроллера"?
ИЛ
чем "металогика" отличается от "логики контроллера"?
контроллер передаёт запрос в вызов команды
проверка доступа для этого - перпендикулярная задача
так же как и валидация команды
проверка доступа для этого - перпендикулярная задача
так же как и валидация команды
A
можно свой атрибут написать и в сабскрайбере его чекать
проверка прав доступа - это всё же металогика, а не логика контроллера
проверка прав доступа - это всё же металогика, а не логика контроллера
логика контролера это просто flow of control
AC
контроллер передаёт запрос в вызов команды
проверка доступа для этого - перпендикулярная задача
так же как и валидация команды
проверка доступа для этого - перпендикулярная задача
так же как и валидация команды
зачем валидировать команду, когда можно валидировать данные в запросе?
ИЛ
если мы по сто раз будем писать одно и то же, то вот это вот одно и то же будет металогикой, которую надо вынести на другой слой
AC
и быть уверенным что тебе данные в команду уже падают валидными?
ИЛ
зачем валидировать команду, когда можно валидировать данные в запросе?
например, ты создаёшь домены пользователям, как ты в запросе провалидируешь уникальность или ограничение количества?
ИЛ
и быть уверенным что тебе данные в команду уже падают валидными?
данные не в команду должны попадать валидные, а в обработчик
ИЛ
запрос ничего не знает о команде
ИЛ
он может на команду мапиться или не мапиться
ИЛ
но о логике команды, что допустима только латинница, например, на уровне запроса неизвестно
AC
например, ты создаёшь домены пользователям, как ты в запросе провалидируешь уникальность или ограничение количества?
так эти валидации можно сделать только в обработчике, если мы говорим про тот же мессенджер, где команда- класс для данных, в него уже поступают валидное дто из контроллера, а в хендлере выполняется логика + какая то валидация связанная с бд
ИЛ
так эти валидации можно сделать только в обработчике, если мы говорим про тот же мессенджер, где команда- класс для данных, в него уже поступают валидное дто из контроллера, а в хендлере выполняется логика + какая то валидация связанная с бд
в миддлваре ещё можно, а валидацию в аннотациях/атрибутах описывать
ИЛ
вот то что без ущерба выносится в аннотации, это металогика
AC
ну я просто валидирую в резолвере и в контроллер кидаю уже валидное дто(та валидация, которая не работает с бд)