душнить, но это какое-то фреймворк ориентированное программирование. Я никогда не писал на спринге и не учил его, но когда надо было расковырять и перефигачить проект на прошлой работе на спринге, "изучение спринга" заняло совсем немного времени, сравнительно со всем остальным.
Эти все фреймворки одинаковые в своих принципах. Что там учить? Зазубрить как методы классов называются?
быстро понимать какую аннотацию навесить на дто, что бы по ней создавалась правильная модель или не аннотацию а ее надо в конфигурации написать или не написать, а зарегистрировать в фабрике или ... и что бы не тратить на изучение доки пол дня
изучить - как он работает, чтобы иметь больше экспертизы.
ну кмк лучше почитать доку полдня. Мне кажется базовые принципы устройства фреймворков неизменные уже много лет. Дизайн приложения с архитектурной точки зрения гораздо более важен и интересен (а он не зависит от фреймворка по определению), и лучше инвестировать время в это, в понимание работы базовых вещей, а не на заучивание какую аннотацию надо навесить на ДТО. Завтра в этой аннотации javax поменяется на jakartaee, заново все учить придется
ну тот же spring-native - например запускает контекст, дальше обходит все бины - определяет для каждого из них - что рефлекшн, генерит файл класса со статическими инициализациями и генерит пачку json файлов, чтобы скормить в graalvm. Это не похоже на что-то базовое) Кваркус не исключение. Микронафт везде все делает inject без proxy и рефлекшена. По-поему очень разные подходы
ну и соответственно 2 пункт (про то, что дизайн приложения не завсисит от фрейморка) тоже не абсолютен. Если взять подход webflux, то дизайн будет кардинально другим по сравнению с mvc
Ну у вас просто будет другая парадигма а соотвественно и дизайн
не, все три фреймворка абсолютно разные
ну это конкретно способ запуска нативного приложения. Нативная компиляция джава-кода вообще отдельная вещь, и тут скорее надо иметь экспертизу больше в граале и принципах работы JVM. Т.е. вот статическая инициализация, как ее описывать и зачем она нужна - она гораздо подробнее в доке грааля описана. Опять же, зная только sping-native ты так и останешься спринг-разработчиком. Понимая как работает грааль, AOTC ты разберешься и зачем нужна инициализация классов в билд-тайме, и как устроен спринг-нейтив и как будет устроен еще не вышедший что-то-там-нейтив для грааля.
не понял к чему здесь я, но ладно) Я не спорю - именно поэтому лучше развиваться и изучать, а не сидеть в одном спринге Просто начав изучать другие фреймворки spring-native и aot spring - узнаешь про graal и все остальное
Обсуждают сегодня