Комментарии 6
А чем файл со схемой отличается от одного большого класса с кучей вложенный классов-dto'шек?
Ну кроме того, что dto'шки пишутся на привычной java, а язык описания схемы еще нужно освоить.
Кроме того, в dto'шках могут быть удобные методы для работы со свойствами, а в схеме - нет.
Я понимаю, схема удобна в качестве способа публикации API сервиса, но и в этом случае достаточно сгенерировать dto'шки 1 раз и положить их в исходниики.
Какой выигрыш вы получаете постоянно перегенерируя dto'шки по схеме при каждой сборке проекта?
В случае с большим классом необходимо потратить достаточно много времени на его описание в соответствии с примером json ответа сервера. Если ли же будет несколько эндпоинтов, то на каждый из них нужно писать свой большой класс, что увеличивает количество этих классов. А что если нужно написать интеграцию с несколькими серверами? Помимо описания ответа сервера могут быть еще и сложные dto для запросов. Это также дополнительные классы.
В случае генерации, для начала, можно воспользоваться онлайн генератором схемы из примера json ответа сервера. Дальше уже можно использовать эту схему как угодно:
Скорректировать ее по вашему усмотрению (переименовать классы, вынести все в defenitions и тд)
Можно наследоваться от генерируемых файлов, переопределяя свойства, которые необходимы или подкладывать свои реализации. В этом случае нужно в defenitions добавить что-то вроде:
"MyClass": { "existingJavaType": "com.example.demo.MyClass" }И его уже использовать как $ref
Либо же можно просто скопировать сгенерированные файлы в привычное место и просто использовать их как обычные java классы. Тут уже решать вам.
Выигрыш от генерации файлов я вижу следующий:
Генерация классов по готовому json ответу занимает меньше времени, чем описание их вручную (конечно, можно воспользоваться онлайн генераторами классов из json ответа сервера)
Описание всего ответа сразу перед глазами в удобном формате
Гибкая настройка генерации (можно добавить генерацию билдеров одной настройкой плагина)
Можно спрятать большое количество dto файлов, чтобы они не мешали чтению проекта
Возможность подменять внутренние классы своими реализациями
я все еще не понимаю, зачем вам схема и зачем генерировать dto-шки каждый раз при пересборке проекта?
Если вам внешний сервис выдал схему, то да, можно 1 раз сгенерировать dto и положить в исходники. плагин не нужен.
если вам внешний сервис схемы не дал, то по json-у можно сразу сгенерировать dto-шки, минуя схему.
если вы хотите облегчить жизнь тем, кто будет интегрироваться с вашим сервисом, то тут схема, безусловно, поможет. Но зачем в этом случае плагин?
ну, ок. я могу придумать 1 вариант, когда это может быть полезно.
в случае, когда вы выкладываете схему в качестве "документации" к своему сервису, то перегенерация не даст вам забыть поправить собственные dto-шки при изменении файла со схемой.
наверное, единственный полезный вариант использования этого плагина.
но даже в этом случае, я бы генерировал схему по dto-шкам, а не наоборот.
еще мне кажется, что вы как-то пренебрежительно относитесь к dto.
не нужно их скрывать!
это полноценные классы проекта.
их можно (и нужно) обвесить аннотациями для валидатора, в них можно (и нужно) писать трасформирующие/аггрегирующие методы, работающие с полями dto, в них можно(и нужно) реализовывать бизнес логику, основанную на полях этого dto.
del
Давайте еще раз по порядку.
Для чего нужна схема? Я развернуто ответил на этот вопрос в предыдущем комментарии.
Зачем генерировать каждый раз при сборке проекта? Для того, чтобы при изменении схемы генерировались обновленные классы. При просмотре пулл реквестов на много удобнее отслеживать изменения в схеме, нежели в большом количестве классов. Генерация занимает всего доли секунды и практически не влияет на общее время сборки проекта.
По поводу бизнес логики в dto и прочее: что такое dto? Это data transfer object - т.е. простой класс для передачи данных. То, что вы описали идет в разрез с best practices. Dto должны быть простыми и содержать только данные, не содержать бизнес логики, данные должны валидироваться ДО создания dto и т.д.
Это data transfer object - т.е. простой класс для передачи данных. То, что вы описали идет в разрез с best practices.
Покажите пожалуйста эти best practices! DTO вовсе не обязаны буть анемичными и, уж точно, анемичные dto - это не best practices, а просто один из подходов. причем, весьма спорный.
данные должны валидироваться ДО создания dto
Вот это я не понял. Валидируем мы обычно входящие данные. Как вы собрались что-то валидировать ДО создания dto?
Нет, ну возможно, конечно, в самой json-схеме прописать соответствующие проверки (у вас в статье, кстати, об этом ни слова) и окончательно превратить все в реинкарнацию jaxb, но, кажется, цель была не в этом.
Ну и json-схема с валидациями сразу становится монструозной и отвратительно читаемой. Примерно как xsd. Для которой в итоге пришлось писать отдельные инструменты для редактирования.
И это вполне себе относится к следующему аргументу
При просмотре пулл реквестов на много удобнее отслеживать изменения в схеме,
нет. не проще. читать код все давно привыкли. читать язык описания json-схемы - надо привыкать, схема (с валидациями) занимает много экранов и инструментов для удобной работы с json-схемой пока не завезли.
кстати, предлагаю вам почитать о том, почему в свое время все устали работать с xsd-схемами и оценить, все ли старые "болячки" решены в json-схеме
Пишем простую интеграцию с GitHub используя feign и jsonschema2pojo maven plugin