логику только сырые данные ,а как насчёт проверки правильности полученного типа для отправки .Кто как считает DTO могут содержать валидации, к примеру проверки на NULL? Просто запихывать проверки валидации в mapper как то слишком его усложняет, должен ли он содержать такую логику....Мне кажется ,что удобнее всего проверки на Null делать в DTO . Может есть кому возразить на этот счёт или наоборот дополнить что ?
К дто же через сервис обращаешься, там и валидируй
Просто посмотри как сделана валидация в спринг
гуглится как rich model и anemic model
Она обмазана анотациями ,а это уже логика ,пусть и препроцессорная но логика
Как то пафосно называть анотации логикой, они не больше чем метаигформация
@NotNull - тогда этого не должно быть в анемичной модели
Которая влияеет на автогенирацию кода (той же валидации)
зависит от контекста, это не логика а только метаинформация, сама проверка в валидаторе, просто вызов валидатора неявный
Где вы нашли кодогенерацию?
К примеру аннотация @Email
К примеру тут нужна репа с annotation processor, а не название анотации
Обсуждают сегодня