Spring에는 구성이 완료되면 변경되지 않는 구성이 많고 대부분의 Bean의 종속성과 같이 변경할 필요가 없기 때문입니다. 변경되지 않는 모든 구성을 xml에 넣는 것은 의미가 없습니다. 구성이 점점 더 커지게 됩니다. Spring 3.x는 구성이 너무 많다는 비판을 받았으며 구성 기반 프로그래밍이 되었습니다. 말 앞에 카트를 배치하므로 실제로 이러한 거의 정적인 구성을 코드에 넣는 것이 더 좋습니다. XML은 수정이 더 편리하고 컴파일 없이도 적용이 가능하므로 환경과 업무에 따라 변경해야 하는 구성을 XML에 넣어두는 것이 좋습니다. Spring Boot는 Rails의 규칙 기반 구성을 흡수하므로 구성이 많이 줄어듭니다. 그러나 기본 구성이 어떻게 구성되어 있는지 잘 모르면 많은 문제에 직면할 수 있습니다.
저도 이 부분에 대해서는 좀 할 말이 없네요. 꼭 설명을 하자면, Spring 시대 이전의 Java 구성은 필수적(실행 순서에 따라 끝까지 작성)이었는데, Spring Boot 시대에는 선언적 Java 구성(탈중앙화)으로 변경되었습니다. 여러 주석이 달린 메서드에서는 실행 순서가 이에 의존하지 않습니다. application.properties로 다른 많은 구성을 재정의할 수 있습니다. 이 작업은 오래 전에 수행되어야 합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
체인 프로그래밍을 사용하면 코드에 구성을 작성하는 것이 더 직관적이고 간단합니다(일부 구성은 스프링 부트 자체에서 수행됨). . .
Maven 종속성을 사용하는 것이 더 신선합니다.
하지만 함정이 더 많은 것 같아요
Spring에는 구성이 완료되면 변경되지 않는 구성이 많고 대부분의 Bean의 종속성과 같이 변경할 필요가 없기 때문입니다. 변경되지 않는 모든 구성을 xml에 넣는 것은 의미가 없습니다. 구성이 점점 더 커지게 됩니다. Spring 3.x는 구성이 너무 많다는 비판을 받았으며 구성 기반 프로그래밍이 되었습니다. 말 앞에 카트를 배치하므로 실제로 이러한 거의 정적인 구성을 코드에 넣는 것이 더 좋습니다.
XML은 수정이 더 편리하고 컴파일 없이도 적용이 가능하므로 환경과 업무에 따라 변경해야 하는 구성을 XML에 넣어두는 것이 좋습니다.
Spring Boot는 Rails의 규칙 기반 구성을 흡수하므로 구성이 많이 줄어듭니다. 그러나 기본 구성이 어떻게 구성되어 있는지 잘 모르면 많은 문제에 직면할 수 있습니다.
저도 이 부분에 대해서는 좀 할 말이 없네요.
꼭 설명을 하자면, Spring 시대 이전의 Java 구성은 필수적(실행 순서에 따라 끝까지 작성)이었는데, Spring Boot 시대에는 선언적 Java 구성(탈중앙화)으로 변경되었습니다. 여러 주석이 달린 메서드에서는 실행 순서가 이에 의존하지 않습니다.
application.properties로 다른 많은 구성을 재정의할 수 있습니다. 이 작업은 오래 전에 수행되어야 합니다.
으아악