스프링 - inflearn

프로젝트가 들어있는 폴더로 이동: hello-study

정적 컨텐츠(static content) 웹 브라우저에서 localhost:8080/hello-static.html 을 내장 톰캣 서버로 요청 ↓ 먼저 스프링 컨테이너에서 hello-static 관련 컨트롤러 찾음 관련 컨틀롤러가 없을시에, resources: stat

스프링 빈을 등록하는 두가지 방법 컴포넌트 스캔과 자동 의존관계 설정 자바 코드로 직접 스프링 빈 등록하기 컴포넌트 스캔과 자동 의존관계 설정 @Component 이 애노테이션이 붙어있으면 스프링 빈으로 자동 등록된다. ⇒ Container에 등록이된다. @Auto

역할과 구현을 분리 interface로 역할을 나타내고 구현체를 바꿔 끼우면 된다.

SRP, DIP, OCP한 클래스는 하나의 책임만 가져야 한다.프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다."의존성 주입은 이 원칙을 따르는 방법 중 하나다.소프트웨어 요소는 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다.

ApplicationContext 를 스프링 컨테이너라 한다.기존에는 개발자가 AppConfig를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용한다.스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정

프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라 한다.기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다.→ 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다.(개발자

스프링 컨테이너 생성 ApplicationContext 를 스프링 컨테이너하고 한다. ApplicationContext 는 인터페이스이다. 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. AppConfig

웹 애플리케이션과 싱글톤 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 그런데, 기존의 것을 계속 이용하면, 고객이 요청할 때마다 객체가 생성되게 된다. → 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를

컴포넌트 스캔과 의존관계 자동 주입 시작하기 지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean 이나 XML의 `` 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다. 예제에서는 몇개가 안되었지만, 이렇게 등록해야 할 스프링 빈이 수십, 수백개가 되면,

다양한 의존관계 주입 방법 생성자에 null 허용이 아니라면, 보통 항상 인자를 채워 넣는다. 생성자가 하나라면, @Autowired 를 붙여주지 않아도 된다. new 로 생성하는애는 빈으로 가져온 애가 아니기 때문에, 스프링으로 가져온 애가 아니다. 따라서 @Au

빈 생명주기 콜백 시작

빈 스코프란? >빈이 존재할 수 있는 범위 스프링이 지원하는 스코프 싱글톤 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다. 프로토 타입 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는

스프링 부트 로깅 라이브러리는 기본으로 다음 로깅 라이브러리를 사용한다.1\. SLF4J - http://www.slf4j.org 2\. Logback - http://logback.qos.chprivate Logger log = LoggerFacto

리터럴 대체 - |...| |...| :이렇게 사용한다. 타임리프에서 문자와 표현식 등은 분리되어 있기 때문에 더해서 사용해야 한다. 다음과 같이 리터럴 대체 문법을 사용하면, 더하기 없이 편리하게 사용할 수 있다. 결과를 다음과 같이 만들어야 하는데 그냥 사용하