스프링에서 객체 생성 책임지고 의존성 관리하는 컨테이너
• POJO의 생성, 초기화, 서비스, 소멸에 대한 권한 가짐
• 장점: 객체 관리 주체가 프레임워크, 즉 컨테이너가 되기 때문에 개발자는 로직에 집중 가능
스프링 컨테이너가 관리하는, 즉 스프링이 직접 생성하고 의존관계 부여하는 객체
• 가장 기본적인 IoC 컨테이너이자 클래스
• 빈 생성하고 관계 설정하는 IoC의 기본 기능에 초점
• 빈팩토리 상속 받아 확장한 것으로, 보통 권장되는 방식
• 빈팩토리의 모든 기능 포함하면서 추가 기능 제공
ex1) 국제화 지원되는 텍스트 메시지 관리
ex2) 이미지같은 파일 자원 로드할 수 있는 포괄적인 방법 제공
ex3) 리스너로 등록된 빈에게 이벤트 발생 알려줌
• 빈의 생성, 관계 설정 등 제어 총괄하는 것에 초점
1-1. ApplicationContext는 @Configuration
이 붙은 클래스들을 설정 정보로 등록
1-2. 해당 클래스 안에 존재하는 @Bean
붙은 메소드의 이름으로 빈 목록 생성
2. 클라이언트가 해당 빈 요청
3. ApplicationContext는 자신의 빈 목록에서 요청한 이름 있는지 탐색
4. 설정 클래스(Configuration Class)로부터 빈 생성 요청하고 생성된 빈 반환
=> 이처럼 빈 관리는 BeanFactory 상속한 ApplicationContext가 관련 모든 작업 총괄
@Configuration
적용@Bean
어노테이션 적용@Configuration
붙어 있는 클래스 찾아 파싱 후, @Bean
붙은 오브젝트를 빈 객체로 등록컴포넌트 스캔 통해 @Component
붙은 모든 오브젝트를 빈으로 자동 등록
• 클래스에만 사용
• 애플리케이션의 비즈니스 로직 구현하는 서비스나 레포지토리 같이 개발자가 직접 변경 가능한 대상에 사용
• 스프링에서 직접 싱글톤 형태의 오브젝트 만들고 관리하는 기능 제공
• 기본 싱글톤 패턴의 반점 보완 => 싱글톤 패턴과 달리 스프링이 지지하는 객체지향적 설계 방식과 원칙, 디자인 패턴 등 적용하는 데 제약 X
+) 싱글톤 개념은 오브젝트 생성 측면에서 자원 소모 효율적으로 하기 위해 등장
• 메서드나 클래스가 빈 로딩 요청받는 시점에 인스턴스 만들고 로딩
• 모든 싱글톤 빈들이 인스턴스화 되므로 빈이 여러 개라면 시간 소요
• 자주 사용되지 않는 빈이라면 소모되는 자원 절약 가능
• 모든 빈들과 설정 파일들이 ApplicationContext에 의해 로드 요청될 때 인스턴스로 만들어지고 로딩
• 미리 만들어진 빈들이 클라이언트로 리턴
• 자주 사용되는 빈이라면 한번에 로드 가능
@Profile
애플리케이션의 실행 환경에 따라 빈 다르게 구성할 때 사용
ex) 개발 환경과 운영 환경에서 서로 다른 빈 사용하고 싶을 때
@Conditional
특정 조건 만족할 때만 빈 등록
스프링 4.0부터 등장
@ConditionalOnProperty
프로퍼티의 조건에 따라 작동
환경 속성 있고 특정 값 있는 경우에만 빈 등록
@ConditionalOnMissingBean
특정 빈이 ApplicationContext에 없는 경우 빈 등록
@ConditionalOnClass
특정 클래스가 경로에 있을 때만 빈 등록
@ConditionalOnMissingClass
특정 클래스가 경로에 없을 때만 빈 등록
자주 사용하는 수많은 빈들을 자동으로 등록해주는 기능
• 반복적으로 빈 등록 및 설정하는 부분 줄임으로써 편리한 개발 가능
• 스프링 부트의 핵심 장점!
• 오른쪽 세 개의 어노테이션이 하나로 합쳐진 형태
• 스프링 부트의 설정 나타내는 어노테이션
• 스프링의 @Configuration
대체하는 스프링 부트 전용 필수 어노테이션
• 자기 자신부터 시작해서 하위 패키지 싹 훑어 @Component
어노테이션 붙인 클래스들 찾아 빈으로 등록
• 자동 설정 활성화 하는 핵심 어노테이션
=> 이처럼 자동 설정은 개발자가 직접 의존성 설정하고 버전 관리하는 등의 번거로움을 줄여주며, 일관된 구성 방식을 유지하는 데 강력한 도움을 준다.
우선.. main에서 pull 받아 Spring/Week2에 src 파일 등등을 넣다보니까 자꾸만 경로 관련 알 수 없는 오류가 떠서ㅠㅠ (지난번에 push 안 된 것도 이 이유일지도?) 결국 바깥에 두었다는 점...을 말씀 드립니다 하하^^ 이에 따라 새로운 브랜치 파서 지난 과제부터 다시 했답니다~ (기존 브랜치는 삭제 완료)
자동 설정 모듈 생성
build.gradle 의존성에 자동 설정 추가
자동 설정 클래스 작성
resources에 META-INF 디렉토리 만들고, 그 안에 spring.factories 파일 만들어 자동 설정 등록
<개요>
• 스프링 부트 정적 컨텐츠 => 파일 그대로 웹 브라우저에 전달
• MVC와 템플릿 엔진 => 서버에서 변형해서, html을 바꿔서 내려주는 방식
• API => JSON이라는 데이터 구조 포맷으로 클라이언트에게 데이터 전달! 클라이언트(리액트, 뷰 등)와 통신할 때뿐만 아니라, 서버끼리 통신할 때도 많이 쓰임
resources/static에 hello-static.html 파일 작성하고 빌드한 뒤, localhost8080/hello-static.html 접속하기
• View => 화면 관련
• Controller => 비즈니스 로직 및 서버 뒷단 관련
HelloController에 코드 추가하고 빌드한 뒤, localhost8080/hello-mvc?name=spring!!! 접속하면 화면에 hello spring!!! 나타남
1. 웹브라우저에서 localhost:8080에 hello-mvc 넘기면, 스프링부트 띄울 때 같이 띄우는 내장 톰켓 서버 먼저 거침
2. 스프링은 helloController에 Mapping 되어있는 것 확인 후 메서드 호출하고 return할 때 key인 name과 값인 spring을 스프링에 넘겨줌
3. 스프링은 viewResolver, 즉 화면 관련 해결자에게 연결시켜줌
4. viewResolver는 templates에서 hello-template이라는 return의 스트링 네임과 똑같은 파일 찾아 Thymeleaf 템플릿 엔진에게 처리해달라고 넘김
5. 템플릿 엔진이 랜더링해서 변환한 HTML을 웹 브라우저에 반환
+)정적일 때는 변환하지 않고 그냥 반환했었음
소스 보기 클릭 시 HTML 태그 사라진 것을 확인할 수 있음
JSON 방식 - 최근에는 거의 이 방식으로 통일, 즉 JSON으로 반환하는 것이 기본 세팅
1. 웹브라우저에 localhost:8080/hello-api 치면 톰켓 내장 서버에서 hello-api 왔다고 스프링에게 던짐
2. 스프링은 @ResponseBody 어노테이션이 있는 것 확인, JSON 방식으로 데이터 만들어 HTTP 응답에 반환하는 것이 디폴트
3. 객체이므로 HttpMessageConverter 중에서도 JsonConverter 동작 (단순 문자일 때는 StringConverter 동작)
4. {name: spring} 웹 브라우저에 반환