[스터디13] 02. 스프링의 개념과 REST API

목차

 

책의 설명이 불친절해서 일부 용어는 직접 찾아보면서 내용을 정리했습니다.

2장. 스프링의 개념과 REST API

2.1 스프링의 패턴과 패러다임 이해하기

스프링은 기본적으로 제어 역전(IoC), 의존성 주입(DI), 관점 지향 프로그래밍(AOP)을 지원한다.

IoC(Inversion of Control)란

• IoC(제어의 역전)는 객체의 생명주기와 의존성 관리의 제어권을 개발자가 아닌 프레임워크에 위임하는 디자인 패턴이다.
• 전통적인 프로그래밍에서는 개발자가 직접 객체를 생성하고 관리했지만, IoC에서는 스프링 컨테이너가 이를 대신 처리한다.

DI(Dependency Injection)란

• 의존성 주입(DI)은 IoC를 구현하는 대표적인 디자인 패턴으로, 객체가 필요로 하는 의존 객체를 외부에서 주입받는 방식이다.
• 스프링은 클래스 구성을 위해 DI를 지원한다.
• DI는 생성자 주입, 설정자 주입, 필드 주입 세 가지 방식으로 구현할 수 있다.
  • 생성자 주입은 불변성을 보장하고 필수 의존성을 명확히 표현할 수 있다.
  • 설정자 주입은 선택적 의존성에 사용되며, 필드 주입은 코드가 간결하지만 테스트가 어렵다.

AOP(Aspect-Oriented Programming)란

• AOP(관점 지향 프로그래밍)는 횡단 관심사를 모듈화하여 비즈니스 로직과 분리하는 프로그래밍 패러다임이다.
• 로깅, 트랜잭션 관리, 보안, 예외 처리 등 여러 모듈에 공통적으로 적용되는 기능을 별도로 관리할 수 있다.
• AOP는 횡단 관심사를 추상화하고 캡슐화하며, 코드의 여러 부분에 걸쳐 관점 동작을 추가하고, 코드를 쉽게 유지하고 확장할 수 있도록 횡단 관심사에 대한 코드를 모듈화한다.
• 주요 개념으로는 Aspect(관점), Advice(충고), Join Point(결합점), Pointcut(포인트컷) 등이 있다.

2.2 IoC 컨테이너 이해하기

• 애플리케이션을 위해 객체라고도 부르는 n개의 bean을 생성한다. bean은 다른 객체의 작동을 요구하는 의존성을 가진다. IoC 컨테이너는 bean을 생성할 때 객체의 의존성을 주입하는 역할을 한다.
• 스프링에서 IoC 원칙을 구현하는 구체적인 방법이 DI이다.
• BeanFactory와 ApplicationContext는 IoC 컨테이너의 기반을 제공하는 중요한 인터페이스다.
  • BeanFactory는 설정 프레임워크와 기본 기능을 제공하고 bean 인스턴스화와 연결을 처리한다.
  • ApplicationContext는 bean 인스턴스화와 연결을 처리할 수 있으며 엔터프라이즈에 특화된 기능들을 제공한다.
• 최신 bean 관리 외에도 추가할 수 있는 여러 기능들이 있기 때문에 스프링은 ApplicationContext의 사용을 권장한다.

2.3 Bean과 그 범위 정의하기

• 빈은 IoC 컨테이너가 관리하는 자바 객체를 의미한다.
• 개발자는 설정 메타데이터(Configuration metadata)를 IoC 컨테이너에 제공하며, IoC 컨테이너는 이 설정 메타데이터를 이용해서 bean을 생성, 어셈블, 관리한다.
• Bean은 컨테이너 내부에서 고유 식별자(unique identifier)을 가져야 한다. 별칭(alias)를 사용하면 두 개 이상의 아이덴티티를 가질 수 있다.

@ComponentScan 애너테이션

• @ComponentScan은 스프링이 컴포넌트를 자동으로 검색하고 빈으로 등록하도록 지시하는 애너테이션이다.
• 지정된 패키지와 하위 패키지를 스캔하여 @Component, @Service, @Repository, @Controller 등의 애너테이션이 붙은 클래스를 찾아 빈으로 등록한다.
• basePackages 속성을 사용하여 스캔할 패키지를 명시적으로 지정할 수 있다.
• 둘 이상의 @ComponentScan을 사용하려는 경우 @ComponentScans 내부에 넣을 수 있다.

Bean의 범위

• 싱글톤(singleton): 스프링의 기본 범위로, IoC 컨테이너당 하나의 인스턴스만 생성한다.
• 프로토타입(prototype): 빈을 요청할 때마다 새로운 인스턴스를 생성한다.
• 요청(request): HTTP 요청당 하나의 인스턴스가 생성된다. (웹 인식 컨텍스트 전용)
• 세션(session): HTTP 세션당 하나의 인스턴스가 생성된다. (웹 인식 컨텍스트 전용)
• 응용 프로그램(application): 유효한 ServletContext당 하나의 인스턴스가 생성된다. (웹 인식 컨텍스트 전용)
• 웹소켓(websocket): 각 WebSocket 세션에 대해 단일 인스턴스가 생성된다.  (웹 인식 컨텍스트 전용)

2.4 자바를 사용하여 bean 설정

• 스프링 3부터 자바 언어로 bean을 정의할 수 있다. (책에서는 스프링 3 이전이라고 표기되어 있으나, 스프링 3 이전에는 XML 설정을 주로 사용했다.)
• 스프링 3에서는 자바를 사용하여 스프링 bean을 설정하고 정의하기 위해 @Configuration, @Bean, @import, @DependsOn 애너테이션을 도입했다.

@Import 애너테이션

• @Import는 다른 설정 클래스를 현재 설정에 포함시킬 때 사용한다.
• 설정을 모듈화하여 관리할 수 있게 해주며, 자동 설정된 클래스들에서 bean의 정의를 가져오므로 컨텍스트를 수동으로 인스턴스화할 때 유용하다.

@DependsOn 애너테이션

• @DependsOn은 특정 빈이 다른 빈보다 먼저 생성되어야 할 때 사용한다.
• Bean의 초기화 순서가 잘못되면서 스프링 컨테이너가 의존성을 찾지 못해 발생하는 NoSuchBeanDefinitionException 예외를 막고, XML이 아닌 자바를 사용하여 bean을 설정할때 초기화 순서를 제어할 수 있다.

2.5 DI 코딩 방법

생성자로 의존성 정의

• 생성자 주입은 객체 생성 시점에 필요한 모든 의존성을 주입받는 방식이다.
• final 키워드를 사용하여 의존성의 불변성을 보장할 수 있다.
• 필수 의존성을 명확히 표현하고 순환 의존성을 조기에 발견할 수 있다.
• 스프링 4.3 이후 생성자가 하나만 있으면 @Autowired를 생략할 수 있다.

설정자 메소드로 의존성 정의

• 설정자 주입은 설정자 메서드를 통해 의존성을 주입하는 방식이다.
• 선택적 의존성을 표현할 때 적합하다.
• 런타임에 의존성을 변경할 수 있지만, 불변성을 보장할 수 없다.

클래스 프로퍼티를 사용한 의존성 정의

• 필드 주입은 필드에 직접 @Autowired를 붙여 의존성을 주입받는 방식이다.
• 코드가 간결하지만 테스트가 어렵고 순환 의존성 발견이 늦다.

2.6 애너테이션을 사용하여 bean의 메타데이터 설정

@Autowired 사용 방법

• @Autowired는 스프링이 자동으로 의존성을 주입하도록 지시하는 애너테이션이다.
• 필드, 생성자, 설정자 또는 모든 메서드에 적용할 수 있다.

일치 종류

• 타입별 일치(type matching): 스프링은 먼저 타입을 기준으로 주입할 빈을 찾는다. 동일한 타입의 빈이 하나만 있으면 바로 주입된다.
• 한정자 일치(qualifier matching): @Qualifier 애너테이션을 사용하여 특정 빈의 이름을 명시적으로 지정할 수 있다. 동일한 타입의 빈이 여러 개 있을 때 유용하다.
• 이름 일치(name matching): 필드나 매개변수의 이름이 빈의 이름과 일치하면 해당 빈이 주입된다.

@Primary의 목적

• @Primary는 동일한 타입의 빈이 여러 개 있을 때 우선적으로 주입될 빈을 지정하는 애너테이션이다.
• @Qualifier보다 우선순위가 낮다.

@Value의 사용 시기

• @Value는 프로퍼티 파일의 값을 빈에 주입할 때 사용한다.
• application.properties나 application.yml 파일에 정의된 설정 값을 읽어올 수 있다.

2.7 AOP용 코드 작성

• AOP는 로깅, 트랜잭션, 보안 등과 같은 횡단 관심사를 해결하는 프로그래밍 패러다임이다.
• 횡단 관심사는 AOP에서 관점(aspect)이라고도 불린다.
• @Around는 Advice를 정의하는 메서드 애너테이션이다. Advice는 특정 시간(JoinPoint)에 Aspect가 취하는 액션이다.
• Advice 종류
  • @Before: Advice가 JoinPoint보다 먼저 실행된다.
  • After: JoinPoint 이후에 실행되는 Advice로 세 가지 하위 타입이 있다.
    • @After: Advice는 메서드의 성공과 실패에 상관없이 JoinPoint 이후에 실행된다.
    • @AfterReturning: JoinPoint가 성공적으로 실행된 후 Advice가 실행된다.
    • @AfterThrowing: JoinPoint에서 예외가 발생한 후 Advice가 실행된다.
  • @Around: Advice가 JoinPoint 전후에 실행된다.
• JoinPoint를 사용하면 대상 객체(target object)와 프록시(proxy)를 캡처할 수 있다.

2.8 서블릿 디스패처의 중요성 이해

• DispatcherServlet은 스프링 MVC의 프론트 컨트롤러로 모든 HTTP 요청을 처리한다.
• REST 컨트롤러를 위한 스프링 MVC의 사용자 요청 처리 흐름
  1. 클라이언트의 HTTP 요청을 DispatcherServlet이 수신한다.
  2. HandlerMapping을 통해 요청을 처리할 컨트롤러를 찾는 작업을 수행한다.
  3. HandlerAdapter를 사용해 컨트롤러를 처리한다.
  4. 컨트롤러가 적절한 메소드를 호출한다. 그리고 비즈니스 로직을 처리하고 결과를 반환한다.
  5. 스프링은 자바에서 JSON/XML 변환을 위해 요청 및 응답 객체의 마샬링(marshalling)/언마샬링(unmarshalling)을 사용한다. 반대의 경우도 마찬가지다.

 

이 글은 『스프링 6와 스프링 부트 3로 배우는 모던 API 개발』 책의 내용을 바탕으로 작성되었습니다.