Я согласен, что именно вашего примера там нет и прямо сейчас я не могу его привести. Мои ответы выше всего лишь констатируют нарастающие попытки государств регулировать общение в сети.
Смысл в том, что когда кого-то закрывают здесь, то в комментариях включается режим "правительство лютует, не то что там".
Когда же выясняется, что "там" тоже есть свой товарищ майор и беспредел случается, то включается режим "мне не интересно как там, мне интересно, как здесь".
Я без понятия, сколько в итоге получится аннотаций, так как с MVC почти не работаю.
Я констатирую факт: настройка проекта с помощью кода стала де-факто стандартом. Загрузка классов работает несравнимо быстрее чтения и разбора ХМЛ-а, а настройки, привязанные к профилям выносятся в application-*.yml. Это сегодняшний день. ХМЛ — день вчерашний за редкими исключениями.
Если собирать проект без среды разработки, то ошибка компиляции всё равно станет видна ещё до запуска. В случае с хмл ошибка станет видна только после запуска.
Потому что банально надо было обеспечить более быстрый и удобный запуск для программистов.
Потому что ява более гибкая, чем хмл. Как вы опишите типизацию бина в хмл-е? Никак. А в яве это раз плюнуть, и опять же ошибка станет ошибкой сборки, а не времени исполнения.
Документацию пишут разработчики фрейворка, имеющие огромный опыт его разработки, внедрения, поддержки. Вы задумывались, почему вообще появился ява-конфиг? Ведь xml-конфиг уже существовал. Но разработчики почему-то заморочились и сделали другое решение.
Если взять ваш секьюрити xml, и выкусить из него описание какого-нибудь бина, то ошибку вы не увидите до запуска приложения.
А если написать ява-конфиг, при чём не передавать зависимости паарметрами в метод, а использовать вызов (как я показал в статье), то выкусывание бина превращается в ошибку компиляции и красный редактор в "Идее".
Это же касается других примеров из статьи. Пакеты и имена классов можно описать в xml-е, ямле и свойствах, вот только опечатка не проявится до запуска. В случае использования классов ошибка в его наименовании/импорте становится ошибкой сборки.
Подавляющее большинство приложений, написанных с нуля, используют именно ява-конфиг. ИМХО, распространённость технологии/подхода есть производная от её/его удобства/полезности.
Можно, только плюс ява-конфига в том, что ошибки/очепятки очень часто становятся ошибками компиляции. А у вас битый xml-конфиг упадёт только при запуске.
В том-то и дело, что приведённый выше код — это типичный бойлерплейт, от которого спасает Спринг. Примеров, когда обычных средсв Спринга не хватает, не привёл никто. Только общие фразы и намёки.
Если сущностей сотни-полторы, то легко. А если есть ещё и Spring Data, то добавьте время проверки запрсов (они проверяются при поднятии контекста). Я об этом ранее писал: https://habr.com/ru/post/439918/
Выпиливание лишней зависимости даёт -20 секунд ко времени запуска приложения.
Я работаю со Спрингом уже 6 лет и приходилось решать довольно головоломные задачи. Иногда приходилось лазить в кишки, да. В 1 особом случае из 100. Во всех остальных хватало яндекса и СО.
Поэтому любой, кто погружается в спринг, всегда будет обязан долго и нудно изучать его недра
Без примеров (пока я не увидел не одного) всё это общие слова. Как правило (сужу по своему опыту) человек, лезущий в кишки в 9/10 невнимательно прочитал документацию. А она в Спринге удивительно хороша, покрывает почти все тонкости.
Опять же накоплен огромный опыт, который позволяет 99 задач из 100 решить одним поисковым запросом.
В демократическом твиттере/ФБ ровно та же история. Могут завести, а могут и не завести, в зависимости от содержимого. Ровно как и ВК. Вы, конечно, можете понадеятся на правосудие, может быть вас даже оправдают (как Кевина Спейси), только вот ваша жизнь/карьера будут бесповоротно испорчены (как у Кевина Спейси).
Существуют ли бенчмарки, подтверждающие это утверждение?
Я согласен, что именно вашего примера там нет и прямо сейчас я не могу его привести. Мои ответы выше всего лишь констатируют нарастающие попытки государств регулировать общение в сети.
Смысл в том, что когда кого-то закрывают здесь, то в комментариях включается режим "правительство лютует, не то что там".
Когда же выясняется, что "там" тоже есть свой товарищ майор и беспредел случается, то включается режим "мне не интересно как там, мне интересно, как здесь".
Такая вот диалектика.
Читайте https://habr.com/ru/post/462771
Не знает, нужно ручками писать. Поэтому когда имена полей совпадают, то лучше марстракт использовть.
Я без понятия, сколько в итоге получится аннотаций, так как с MVC почти не работаю.
Я констатирую факт: настройка проекта с помощью кода стала де-факто стандартом. Загрузка классов работает несравнимо быстрее чтения и разбора ХМЛ-а, а настройки, привязанные к профилям выносятся в
application-*.yml. Это сегодняшний день. ХМЛ — день вчерашний за редкими исключениями.Если полей много и названия разные, то интерфейс по объёму кода может получиться такой же, как и самописный преобразователь.
Если собирать проект без среды разработки, то ошибка компиляции всё равно станет видна ещё до запуска. В случае с хмл ошибка станет видна только после запуска.
Потому что ява более гибкая, чем хмл. Как вы опишите типизацию бина в хмл-е? Никак. А в яве это раз плюнуть, и опять же ошибка станет ошибкой сборки, а не времени исполнения.
Документацию пишут разработчики фрейворка, имеющие огромный опыт его разработки, внедрения, поддержки. Вы задумывались, почему вообще появился ява-конфиг? Ведь xml-конфиг уже существовал. Но разработчики почему-то заморочились и сделали другое решение.
Если взять ваш секьюрити xml, и выкусить из него описание какого-нибудь бина, то ошибку вы не увидите до запуска приложения.
А если написать ява-конфиг, при чём не передавать зависимости паарметрами в метод, а использовать вызов (как я показал в статье), то выкусывание бина превращается в ошибку компиляции и красный редактор в "Идее".
Это же касается других примеров из статьи. Пакеты и имена классов можно описать в xml-е, ямле и свойствах, вот только опечатка не проявится до запуска. В случае использования классов ошибка в его наименовании/импорте становится ошибкой сборки.
Подавляющее большинство приложений, написанных с нуля, используют именно ява-конфиг. ИМХО, распространённость технологии/подхода есть производная от её/его удобства/полезности.
Можно, только плюс ява-конфига в том, что ошибки/очепятки очень часто становятся ошибками компиляции. А у вас битый xml-конфиг упадёт только при запуске.
Список путей в ямле +
@Valueв ява-конфигурацииВ том-то и дело, что приведённый выше код — это типичный бойлерплейт, от которого спасает Спринг. Примеров, когда обычных средсв Спринга не хватает, не привёл никто. Только общие фразы и намёки.
Spring Data JPA работает поверх хибернейта. Использовать Хибернейт сам по себе в 2019 г смысла нет, кмк.
Если сущностей сотни-полторы, то легко. А если есть ещё и Spring Data, то добавьте время проверки запрсов (они проверяются при поднятии контекста). Я об этом ранее писал: https://habr.com/ru/post/439918/
Выпиливание лишней зависимости даёт -20 секунд ко времени запуска приложения.
Я работаю со Спрингом уже 6 лет и приходилось решать довольно головоломные задачи. Иногда приходилось лазить в кишки, да. В 1 особом случае из 100. Во всех остальных хватало яндекса и СО.
Без примеров (пока я не увидел не одного) всё это общие слова. Как правило (сужу по своему опыту) человек, лезущий в кишки в 9/10 невнимательно прочитал документацию. А она в Спринге удивительно хороша, покрывает почти все тонкости.
Опять же накоплен огромный опыт, который позволяет 99 задач из 100 решить одним поисковым запросом.
Хотите спорить — приводите примеры из жизни.
Почитайте документацию. 21 век же.
1) Для этого есть профили: набор файлов
application-dev.yml,application-test.yml,application-int.yml,application-prod.ymlи т.д.2) Если вам лень вносить изменения в файлы, то в
build.gradleпрописываете что-то вродеа в
*.ymlТеперь можно получить сборку с нужными значениями, подставив их в коммандную строку при сборке.
В демократическом твиттере/ФБ ровно та же история. Могут завести, а могут и не завести, в зависимости от содержимого. Ровно как и ВК. Вы, конечно, можете понадеятся на правосудие, может быть вас даже оправдают (как Кевина Спейси), только вот ваша жизнь/карьера будут бесповоротно испорчены (как у Кевина Спейси).
Спасибо за ваш комментарий! Во-первых, я не знал об этом, во-вторых, ваш коммент один из немногих по существу заметки.