создавать / обновлять какой-нибудь объект.
Данные например передаем в json, и при создании объекта нам нужна одна валидация (такие-то поля не пустые и с валидными значениями), а при апдейте объекта другая валидация (все поля опциональные, что-то можно менять, что-то нельзя).
Как вы обычно такую валидацию добавляете?
Один struct с json tags, и скажем 2 метода у него типа .validateCreate() и .validateUpdate()? или что-то еще?
Сначала нужно почитать про разделение логики на слои абстракции. Серебряной пули тут нет, но я советую вступить в секту свидетелей гексагональной архитектуры. Затем требуется решить, на каком слое абстракции делать валидацию. И снова нет серебряной пули: можно сделать на api-слое, можно на слое бизнес-логики. И да, скорее всего, это будут 2 разных валидатора, в зависимости от сложности валидируемого объекта и от того, как сильно различаются эти 2 объекта.
если генерация то она сгенерирует в на апи, а если руками - то проще в логику, тк правила бизнес определяет, плюс источник данных разный может быть и не надо дублировать вызов в валидатора будет
Вопрос дискуссионный, конечно. Например, есть ли другие ручки обновления сущности с использованием той же БЛ, и актуальны ли будут правила валидации там.
приведите пример, где такое было у вас, если можете
Пум-пум… если начну долго расписывать, мы погрузимся в дебри. Короче, там сервис был, у которого был rest-эндпоинт и grpc-ручка, обе они были почти аналогичны по функционалу с тем исключением, что rest-ручка дергалась авторизованным пользователем, и там были реализованы проверки в зависимости от того, что за пользователь. В grpc-ручке этого не было, и требовалась чуть другая валидация. Пильнуть универсальный валидатор было можно, но не хотелось раздувать цикломатическую сложность такого решения.
Обсуждают сегодня