Чрезмерная приверженность регламентам и правилам рождается, как правило, в результате чей-то чрезмерной приверженности их нарушать.
На производстве (it в своем роде и есть производство) важен прагматизм, это не сфера обслуживания. Чем быстрее тебе укажут на ошибку, тем эффективнее пойдут процессы. И пусть хоть как это доносят, лишь бы сработало. Прямые личные оскорбления, конечно, не в счет, а с остальным можно жить.
1. Как минимум, здесь отсутствует типобезопасность.
2. Замечание не на тему того, кто чей клон, а откуда этот файл берется. Его генерирует определенный annotation processor. Кому нужно делать rebuild проекта ради какой-то подсветки? Вся эта каша нужна в библиотеках и стартерах. Или в 2018 кто-то еще зашивает конфиги в поставку?
3. Это нужно не для инжекта бизнес логики в конфиг! А для создания сложных библиотечных конфигураций, завязанных на стандартных интерфейсах из jsl или кастомной абстракции. В примере из статьи присутствует явное нарушение single responsibility principle. ConfigurationProperties нужно использовать либо в автоконфигурации, либо в сервисе, которому эти конфиги нужны (второе решение — так себе). Код из примера можно понять таким образом (а ведь он именно и написан в таком стиле), что надо все бины прятать в конфиги и через конфиги получать к бинам доступ. А потом кто-то жалуется на невозможность зарезолвить циклические зависимости и тратит по неделе на фикс простейшего бага.
2. Еще не хватает объяснения, откуда появляется файл additional-spring-configuration-metadata.json и как он связан с spring-boot-configuration-processor.
3. Статьи на хабре читает много новичков; и инжект сервисов в properties, вы шутите?
И какой смысл использовать всю эту кашу с метаданными вне стартеров?
QueryDsl в spring-data-jpa имеет статус deprecated.
Репа для интеграции со spring не обновлялась уже полтора года.
Выходит, что использовать можно только на свой страх и риск, и вероятно через костыли.
API у него неплох, но и со спецификациями жить тоже можно, хотя бы поддержка есть.
Content-type указывать необязательно, достаточно передать какой-нибудь отличный от базовых типов объект, например ...body(fromObject(myDto)). По факту на выходе автоматом получится json. А вот берет ли на себя webflux корректную расстановку хидеров; это нужно проверить.
Чрезмерная приверженность регламентам и правилам рождается, как правило, в результате чей-то чрезмерной приверженности их нарушать.
На производстве (it в своем роде и есть производство) важен прагматизм, это не сфера обслуживания. Чем быстрее тебе укажут на ошибку, тем эффективнее пойдут процессы. И пусть хоть как это доносят, лишь бы сработало. Прямые личные оскорбления, конечно, не в счет, а с остальным можно жить.
Ну маты и маты. В другом пункте и в тему.
Автор не ханжа, спасибо ему за это.
Процессы до этого не успевали дорасти. Сейчас уже активно используется в одном из топ.
Пост выше был в поддержку второго абзаца. Это как пример того, что без нативных запросов можно наворотить гораздо большее зло.
Все так. Интересно посмотреть, как одними только средствами jpa будут доставать записи по внутренним полям jsonb
2. Замечание не на тему того, кто чей клон, а откуда этот файл берется. Его генерирует определенный annotation processor. Кому нужно делать rebuild проекта ради какой-то подсветки? Вся эта каша нужна в библиотеках и стартерах. Или в 2018 кто-то еще зашивает конфиги в поставку?
3. Это нужно не для инжекта бизнес логики в конфиг! А для создания сложных библиотечных конфигураций, завязанных на стандартных интерфейсах из jsl или кастомной абстракции. В примере из статьи присутствует явное нарушение single responsibility principle.
ConfigurationPropertiesнужно использовать либо в автоконфигурации, либо в сервисе, которому эти конфиги нужны (второе решение — так себе). Код из примера можно понять таким образом (а ведь он именно и написан в таком стиле), что надо все бины прятать в конфиги и через конфиги получать к бинам доступ. А потом кто-то жалуется на невозможность зарезолвить циклические зависимости и тратит по неделе на фикс простейшего бага.2. Еще не хватает объяснения, откуда появляется файл
additional-spring-configuration-metadata.jsonи как он связан сspring-boot-configuration-processor.3. Статьи на хабре читает много новичков; и инжект сервисов в properties, вы шутите?
И какой смысл использовать всю эту кашу с метаданными вне стартеров?
А что будет, если конструктор добавить, уж лучше и не проверять)))
Репа для интеграции со spring не обновлялась уже полтора года.
Выходит, что использовать можно только на свой страх и риск, и вероятно через костыли.
API у него неплох, но и со спецификациями жить тоже можно, хотя бы поддержка есть.