VT
1. Строку валидируешь валидатором.
2. Поведение выносишь в сервис.
И не паришься.
2. Поведение выносишь в сервис.
И не паришься.
Фу
Size: a a a
2020 May 12
M
В чем видишь недостаток такого способа?
VT
В чем видишь недостаток такого способа?
№1
SomeUpdateRequest {
fullName: string,
signature: string
}
....
Author.updateBio(request.fullName, request.fullName); // валидный код, ничего не упало
№2
если под сервисом ты имешь в виду тоже самое, что и большинство остальных, то:
сервис штука сложная, хер пойми где заканчивается его граница ответственности и как покрывать тестами всё это, когда у тебя зависимостей хотя бы штук 5 будет. у сущности\VO зависимостей меньше. переносишь поведение туда -> легче тестировать.
SomeUpdateRequest {
fullName: string,
signature: string
}
....
Author.updateBio(request.fullName, request.fullName); // валидный код, ничего не упало
№2
если под сервисом ты имешь в виду тоже самое, что и большинство остальных, то:
сервис штука сложная, хер пойми где заканчивается его граница ответственности и как покрывать тестами всё это, когда у тебя зависимостей хотя бы штук 5 будет. у сущности\VO зависимостей меньше. переносишь поведение туда -> легче тестировать.
UM
кто знает как это исправить?
UM
M
№1
SomeUpdateRequest {
fullName: string,
signature: string
}
....
Author.updateBio(request.fullName, request.fullName); // валидный код, ничего не упало
№2
если под сервисом ты имешь в виду тоже самое, что и большинство остальных, то:
сервис штука сложная, хер пойми где заканчивается его граница ответственности и как покрывать тестами всё это, когда у тебя зависимостей хотя бы штук 5 будет. у сущности\VO зависимостей меньше. переносишь поведение туда -> легче тестировать.
SomeUpdateRequest {
fullName: string,
signature: string
}
....
Author.updateBio(request.fullName, request.fullName); // валидный код, ничего не упало
№2
если под сервисом ты имешь в виду тоже самое, что и большинство остальных, то:
сервис штука сложная, хер пойми где заканчивается его граница ответственности и как покрывать тестами всё это, когда у тебя зависимостей хотя бы штук 5 будет. у сущности\VO зависимостей меньше. переносишь поведение туда -> легче тестировать.
Не, сервис в смысле класс/классы, которые составляют компонент/слой
VT
Не, сервис в смысле класс/классы, которые составляют компонент/слой
тогда я нихера не понимаю о чём ты конкретно, но всё равно фу
BT
да
UM
VT
@codeflood еще есть
BT
@codeflood еще есть
bitch
VT
bitch
no u
AK
@codeflood еще есть
ты тут не это самое >:(
M
тогда я нихера не понимаю о чём ты конкретно, но всё равно фу
Ну есть сущности у тебя это просто структуры, и есть сервисы, в которых бизнес логика. Вместе они составляют слой высшего уровня, слой предметной области.
VT
Ну есть сущности у тебя это просто структуры, и есть сервисы, в которых бизнес логика. Вместе они составляют слой высшего уровня, слой предметной области.
ну вот об этом я в п.2 написал
ЕР
Ну есть сущности у тебя это просто структуры, и есть сервисы, в которых бизнес логика. Вместе они составляют слой высшего уровня, слой предметной области.
Это уже столько раз тут обсуждалось что похоже на троллинг...
M
Это уже столько раз тут обсуждалось что похоже на троллинг...
Я не видел )
M
ну вот об этом я в п.2 написал
В чем проблема отделять их?