1장 스프링 부트 시작하기

1.1 스프링의 새로운 시작 

 -> 스프링은 JEE나 J2EE로 알려진 자바 엔터프라이즈 에디션을 경량화하려는 대안으로 시작 

 -> 스프링은 무거운 엔터프라이즈 자바빈(EJB)으로 컴포넌트 개발 X

 -> 그 대신 의존성 주입과 관점 지향 프로그래밍( AOP ) 를 활용해

       EJB 기능을 평범한 자바 객체 ( POJO )로 구현해

      간단하게 엔터프라이즈 자바 개발에 접근할 수 있는 방법 제공

 -> 컴포넌트 코드 작성은 가벼웠으나 개발 구성은 무거웠습니다 

     초기 스프링은 구성에 필요한 XML 코드가 多

 -> 스프링 2.5 

     Anootation을 기반으로 한 컴포넌트 검색기능 도입 

     애플리케이션 컴포넌트에 필요한 명시적인 XML 제거 

 -> 스프링 3.0

    XML대신 타입 세이프하고 리팩토링이 가능한 자바 기반의 구성 도입 

BUT 

 여전히 스프링은 복잡한 구성에서 벗어나지 못해

 -> 트랜잭션 관리와 스프링 MVC와 같은 기능을 사용하려면 명시적인 XML 이나 자바 구성 필요 

 -> Thymeleaf 기반의 웹 뷰 같은 서드파티 라이브러리 기능을 사용할 때도 명시적인 구성 필요 

 -> 스프링의 서블릿이나 필터를 구성하려면 web.xml이나 초기화 객체에 명시적 구성 필요 

 -> 컴포넌트 검색은 구성을 줄여주고, 자반 기반 구성은 좀 더 쉽게 스프링 구성을 할 수 있게 

 -> BUT 스프링은 여전히 해야 할 구성 多

 

모든 구성 작업은 개발 저항으로 나타나 애플리케이션 로직 작성 대신 구성 작업에 쓰는 시간은 모두 낭비 

스프링 기능 구성에 정신이 팔리면 비즈니스 문제를 해결하는데 방해 

다른 프레임워크 처럼 스프링은 많은 일을 대신 처리하지만, 그 대가로 여러분이 해야 할 일도 늘어나

 

게다가 프로젝트 의존성 관리는 태가 나지 않는 일 

어떤 라이브러리를 프로젝트 빌드에 포함해야 하는지 결정하는 일은 까다롭다 

프로젝트에 포함한 라이브러리의 어떤 버전이 다른 라이브러리와 잘 작동하는지 알아내기가 어렵다

 

의존성 관리 중요한 문제이지만 빌드에 의존 라이브러리 추가는 애플리케이션 코드 작성하는 일이 아니다

의존 라이브러리의 버전을 잘못 선택해서 발생하는 모든 호환성 문제는 생산성을 망치는 주범 

 

----> 스프링 부트는 이것을 모두 바꿨다