스프링 인 액션(5판) 챕터 1장을 요약한 내용 입니다.

스프링은 스프링 애플리케이션 컨텍스트라는 컨테이너를 제공하는데, 이것은 애플리케이션 컴포넌트들을 생성하고 관리한다. 그리고 애플리케이션 컴포넌트 또는 빈(bean)들은 스프링 애플리케이션 컨텍스트 내부에서 서로 연결되어 완전한 애플리케이션을 만든다.

빈의 상호 연결은 의존성 주입이라고 알려진 패턴을 기반으로 수행된다. 즉, 애플리케이션 컴포넌트에서 의존(사용)하는 다른 빈의 생성과 관리를 자체적으로 하는 대신 별도의 대체(컨테이너)가 해주며, 이 개체에서는 모든 컴포넌트를 생성, 관리하고 해당 컴포넌트를 필요로 하는 빈에 주입(연결)한다. 일반적으로 이것은 생성자 인자 또는 속성의 접근자 메서드를 통해 처리된다.

지금까지의 스프링 버전에서는 컴포넌트 및 다른 컴포넌트 및 다른 컴포넌트와의 관계를 나타내는 하나 이상의 XML 파일을 사용해서 빈을 상호 연결하도록 스프링 애플리케이션 컨텍스트에 알려주었다.

<bean id="inventoryService" class="com.example.InventoryService" />
<bean id="productService" class="com.example.ProductService">
	<constructor-arg ref="inventoryService" />
<bean>

그러나 최신 버전의 스프링에서는 자바 기반의 구성(configuration)이 더 많이 사용된다.

@Configuration
public class ServiceConfiguration {
	@Bean
	public InventoryService inventoryService() {
		return new InventoryService();
	}

	@Bean
	public ProductService productSerivce() {
		return new ProductService(inventoryService());
	}
}

@Configuration 애노테이션은 각 빈을 스프링 애플리케이션 컨텍스트에 제공하는 구성 클래스라는 것을 스프링에게 알려준다. 구성 클래스의 메서드에는 @Bean 애노테이션이 지정되어 있으며, 이것은 각 메서드에서 반환되는 객체가 애플리케이션 컨텍스트의 빈으로 추가되어야 한다는 것을 나타낸다.

스프링은 자동으로 컴포넌트들을 구성할 수 있는 자동-구성 기능이 있다. 자동-구성은 자동 연결과 컴포넌트 검색이라는 스프링 기법을 기반으로 한다. 컴포넌트 검색을 사용하여 스프링은 자동으로 애플리케이션의 classpath에 지정된 컴포넌트를 찾은 후 스프링 애플리케이션 컨텍스트의 빈으로 생성할 수 있다. 또한, 스프링은 자동 연결을 사용하여 의존 관계가 있는 컴포넌트를 자동으로 다른 빈에 주입(연결)한다.

기존의 자바 웹 애플리케이션은 WAR 파일로 패키징되며, JAR 파일은 라이브러리와 데스크톱 UI 애플리케이션의 패키징에 사용되기 때문이다.

JAR 패키징은 클라우드를 염두에 둔 선택이다. WAR 파일은 기존의 자바 애플리케이션 서버에 애플리케이션을 배포할 때는 적합하지만, 대부분의 클라우드 플랫폼에는 잘 맞지 않는다

원하는 구성을 할 수 있는 JAR 포맷과 달리 WAR은 WEB-INF 및 META-INF 디렉토리로 사전 정의 된 구조를 사용하며 WAR파일을 실행하려면 Tomcat, Weblogic, Websphere 등의 웹 서버 (WEB)또는 웹 컨테이너(WAS)가 필요하다.

WAR 파일도 JAVA의 JAR 옵션( java - jar)을 이용해 생성하는 JAR파일의 일종으로 웹어플리케이션 전체를 패키징하기 위한 JAR파일로 생각하시면 될 것 같다.

<?xml version="1.0" encoding="UTF-8"?>
<product xmlns="http://maven.aphache.org/POM/4.0.0"
	...
	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>2.2.6.RELEASE</version>
		<relativePath/>
	</parent>

	<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-thyumeleaf</artifactId>
		</dependency>

		...
	</dependencies>

<parent> 태그는 우리 프로젝트가 부모 POM(Product Object Model)으로 spring-boot-starter-parent를 갖는다는 것을 지정한다. 이 부모 POM은 스프링 프로젝트에 흔히 사용되는 여러 라이브러리의 의존성 관리를 제공한다.

의존성은 <dependencies> 요소에 정의된다. Spring web, Thymeleaf, Test 의존성 항목은 <artifactId>에 stater 단어를 포함하고 있음을 알 수 있다. 스타터 의존성은 다음 세 가지 장점이 있다.

• 우리가 필요로 하는 모든 라이브러리의 의존성을 선언하지 않아도 되므로 빌드 파일이 훨씬 더 작아지고 관리하기 쉬어진다.
• 라이브러리 이름이 아닌 기능의 관점으로 의존성을 생각할 수 있다. 따라서 만일 웹 애플리케이션을 개발한다면 웹 애플리케이션을 작성할 수 있게 해주는 라이브러리들을 일일이 지정하는 대신에 여기처럼 웹 스타터 의존성만 추가하면 된다.
• 라이브러리들의 버전을 걱정하지 않아도 된다. 스프링 부트에 포함되는 라이브러리들의 버전은 호환이 보장되므로 사용하려는 스프링 부트의 버전만 신경 쓰면 된다.

실행 가능 JAR 파일에서 애플리케이션을 실행하므로 제일 먼저 시작되는 부트스트랩 클래스가 있어야 한다.

@SpringBootApplication은 다음 세개 에노테이션이 결합한 적이다.

• @SpringBootConfiguration: 현재 클래스(TacoCloudApplication)를 구성 클래스로 지정한다. 아직은 구성이 많지 않지만, 필요하다면 자바 기반의 스프링 프레임워크 구성을 현재 클래스 추가할 수 있다. 실제로는 이 애노테이션이 @Configuration: 특화된 형태이다.
• @EnableAutoConfiguration : 스프링 부트 자동 구성을 활성화한다. 자동 구성은 나중에 더 자세히 알아볼 것이다. 일단 지금은 이 애노테이션이 우리가 필요로 하는 컴포넌트들을 자동으로 구성하도록 스프링 부트에 알려준다는 것만 알아 두자
• @ComponentScan : 컴포넌트 검색을 활성화한다. 이것은 @Component, @Controller, @Serivce 등의 애노테이션과 함께 클래스를 선언할 수 있게 해준다. 그러면 스프링은 자동으로 그런 클래스를 찾아 스프링 애플리케이션 컨텍스트에 컴포넌트로 등록한다.

@SpringBootTest는 스프링 부트 기능으로 테스트를 시작하는 것을 JUnit에 알려준다.

@Component, @Service, @Repository를 포함해서 소수의 다른 애노테이션들도 @Controller와 동일한 기능을 제공하므로 이런 애노테이션들 중 어느 것을 사용해도 된다. 그러나 @Controller를 선택한 이유는 애플리케이션에서의 컴포넌트 역할을 더 잘 설명해 주기 때문이다.

@WebMvcTest(HomeController.class)
public class HomeControllerTest {
	...
}

@SpringBootTest 대신 @WebMvcTest 애노테이션을 사용하면 스프링 MVC 애플리케이션의 형태로 테스트가 실행되도록 한다. 즉, HomeController가 스프링 MVC에 등록되므로 우리가 스프링 MVC에 웹 요청을 보낼 수 있다.

@WebMvcTest는 또한 스프링 MVC를 테스트하기 위한 스프링 지원을 설정한다. 이때 우리 테스트에서는 실제 서버를 시작하는 대신 스프링 MVC의 모킹(mocking) 매커니즘을 사용해도 충분하므로 모의 테스트를 하기 위해 우리 테스트 클래스에 MockMvc 객체를 주입(연결)한다.

DevTools는 스프링 개발자에게 다음과 같은 개발 시점의 편리한 도구를 제공한다.

• 코드가 변경될 때 자동으로 애플리케이션을 다시 시작시킨다. (**단점은 애플리케이션이 자동으로 가시 시작될 때 의존성 변경이 적용될 수 없다**)
• 브라우저로 전송되는 리소스(예를 들어, 템플릿, 자바스크립트, 스타일시트)가 변경될 때 자동으로 브라우저를 새로고침한다.
• 템플릿 캐시를 자동으로 비활성화한다.
• 만일 H2 데이터베이스가 사용 중이라면 자동으로 H2 콘솔을 활성화한다.

스타터 의존성과 자동-구성 외에도 스프링 부트는 다음의 다른 편리한 기능도 제공한다.

• 액추에이터는 애플리케이션의 내부 작동을 런타임 시에 살펴볼 수 있는 기능을 제공하며, 여기에는 메트릭, 스레드 덤프 정보, 애플리케이션의 상태, 애플리케이션에서 사용할 수 있는 환경 속성이 포함된다.
• 환경 속성의 명세
• 핵심 프레임워크에 추가되는 테스트 지원

간단한 자바 인터페이스로 애플리케이션의 데이터 리파지터리를 정의할 수 있다. 스프링 데이터는 서로 다른 종류의 데이터베이스와 함께 사용될 수 있다.

스프링 시큐리티는 인증, 허가, API 보안을 포함하는 폭넓은 범위의 애플리케이션 보안 요구를 다룬다.

스프링 통합은 데이터가 사용 가능한 즉시 처리되는 실시간 통합을 한다. 반면에 스프링 배치에서는 다량의 데이터가 처리되는 시점을 트리거가 알려줄 때 데이터가 수집 처리되는 배치 통합을 처리해 준다.

• 웹 애플리케이션 생성, 데이터베이스 사용, 애플리케이션 보안, 마이크로서비스 등에서 개발자의 노력을 덜어주는 것이 스프링의 목표다
• 스프링 부트는 손쉬운 의존성 관리, 자동-구성, 런타임 시의 애플리케이션 내부 작동 파악을 스프링에서 할 수 있게 한다.
• 스프링 애플리케이션은 스프링 Initializer를 사용해서 초기 설정할 수 있다.
• 빈이라고 하는 컴포넌트는 스프링 애플리케이션 컨텍스트에서 자바나 XML로 선언할 수 있으며, 컴포넌트 탐색으로 찾거나 스프링 부트 자동-구성에서 자동으로 구성할 수도 있다.

원하는 구성을 할 수 있는 JAR 포맷과 달리 WAR은 WEB-INF 및 META-INF 디렉토리로 사전 정의 된 구조를 사용하며 WAR파일을 실행하려면 Tomcat, Weblogic, Websphere 등의 웹 서버 (WEB)또는 웹 컨테이너(WAS)가 필요하다.

WAR 파일도 JAVA의 JAR 옵션( java - jar)을 이용해 생성하는 JAR파일의 일종으로 웹어플리케이션 전체를 패키징하기 위한 JAR파일로 생각하시면 될 것 같다.