Spring

Spring, Spring Boot

TeoJeon 2023. 1. 13. 12:12

스프링이란?

좋은 객체 지향 어플리케이션을 만들 수 있게 도와주는 프레임워크

 

이를 돕는 기술로는

  • IoC(IoC : Inversion of Control)(제어 역전) 컨테이너
    • 스프링의 가장 중요하고 핵심적인 기술
    • DI(Dependency injection)을 통해 각 계층이나 서비스들간의 의존성을 맞춰줌.
    • 객체의 생명주기 관리
  • AOP(Aspect-Oriented Programming)
    • 로깅, 보안, 트랜잭션 등 핵심적인 비즈니스 로직과는 관련이 없으나 여러 곳에 공통적으로 쓰이는 기능들을 분리하여 개발하고 실행 시에 조합하는 기법

이 밖에도

  • 데이터 액세스 프레임워크
  • 트랜잭션 관리 프레임워크
  • MVC 패턴
  • Batch 프레임워크

등의 모듈을 가지고 있음

스프링 부트란?

: 스프링을 편리하게 사용할 수 있도록 각종 라이브러리들과 설정을 패키징해서 제공하는 툴

  • Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨.
  • 손쉬운 빌드 구성을 위한 starter(Spring을 사용할 때 많이 사용하는 라이브러리의 묶음) 종속성 제공
  • 관례에 의한 간결한 설정파일 제공

위에서 좋은 객체지향 설계라고 했는데 좋은 객체지향 설계란 무엇일까?

좋은 객체지향 설계란?(SOLID)

SOLID : 클린코드로 유명한 로버트 마틴이 좋은 객체지향 설계의 5가지 원칙을 정리한 용어

  • SRP: 단일 책임 원칙(Single Responsibility Principle)
    • 유지보수를 위해 한 클래스는 하나의 책임만 가져야 함.(개인적으로 한 문장으로 표현할 수 있으면 될 거 같다고 생각함)
    • 중요한 기준은 변경
  • OCP: 개방-폐쇄 원칙(Open/Close principle)
    • 확장에는 열려있으나 변경에는 닫혀있어야 한다.
  • LSP: 리스코프 치환 원칙(Liskov Substitution Principle)
    • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 함.
    • 인터페이스를 구현할 때 해당 인터페이스의 규약을 정확히 지켜야 함.
    • ex) increase()라는 메서드를 만들 때 증가시키는 방향의 기능으로 구현해야지 감소시키는 방향으로 구현하면 LSP 위반
  • ISP: 인터페이스 분리 원칙(Interface Segregation Principle)
    • 범용 인터페이스가 아니라 클라이언트의 종류마다 별개의 인터페이스를 두는 것이 좋음
    • 그래야 한 종류의 클라이언트만을 위해서 인터페이스를 수정할 때 다른 종류의 클라이언트가 영향을 받지 않음.
  • DIP: 의존관계 역전 원칙(Dependency Inversion Principle)
    • 구현 클래스에 의존하지 않고, 인터페이스에 의존해야 함.
    • 인터페이스에 의존해야 상황에 맞춰서 같은 인터페이스로 구현한 여러 구현체를 사용할 수 있음.

순수 자바 코드만으로는 OCP, DIP를 지키기 힘듦.

→ DI 컨테이너를 통해 객체를 주입하면서 OCP, DIP를 지킬 수 있게 됨.

** 다형성을 지키기 위해 모든 클래스를 구현하기 전에 인터페이스를 만들면 추상화라는 비용이 발생함. 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 꼭 필요할 경우 리팩토링해서 인터페이스를 도입하는 것도 방법

Bean

스프링 컨테이너에 의해 관리되는 자바 객체(POJO)

  • 두가지 방법으로 등록할 수 있음
    • @Configuration으로 등록한 Config 클래스에서 등록하고 싶은 클래스를 생성하는 메서드에 @Bean을 붙이는 것으로 등록
    • @Component를 해당 클래스 또는 인터페이스 위에 붙이는 것으로 등록
  • @Bean은 개발자가 컨트롤이 불가능한 외부 라이브러리들을 Bean으로 등록하고 싶은 경우 사용
  • @Component는 개발자가 직접 컨트롤이 가능한 클래스들에 사용
  • @Controller, Repository, Service, Configuration과 같은 곳에 Component가 포함되어 있어서 해당 어노테이션을 붙이면 빈에 등록됨.
  • 기본적으로 싱글톤으로 관리되어 어플리케이션과 생명주기를 함께함.
  • 어플리케이션을 시작할 때 모든 Bean을 생성해서 가지고 있다가 객체를 생성할 때 의존하는 객체를 주입해줌.
  • 뒤에 나올 Bean Scope로 생명주기를 변경할 수 있음

 

싱글톤

객체를 사용할 때마다 새로 생성하는 것은 비용이 매우 큼.

그래서 프로그램 안에서 해당 객체를 딱 하나 생성하고 하나의 객체를 여러 곳에서 참조해서 사용함으로써 리소스를 절약

 

원칙

  • 싱글톤 객체 내부에 값을 바꾸는 필드가 존재해선 안됨.
    • 여러 코드에서 같은 객체에 접근하기 때문에 값을 바꾸는 필드를 참조할 경우 의도치 않은 상황이 발생함.

의존관계 주입 방법

  • 생성자 (권장)
  • 수정자(setter)
  • 메서드를 통해 필드에 직접

Bean 중복 문제

스프링이 객체를 생성할 때 객체 내부에 의존하는 클래스가 있는 경우 필드의 타입으로 찾아서 주입함.

이 때 같은 타입의 객체가 여러 개일 경우 (필드의 타입이 인터페이스고, 해당 인터페이스를 구현한 클래스가 2개일 경우) 충돌이 일어남

해결방법

  • @Qualifier
    • Qualifier로 각 구현 클래스에 이름을 등록하고 원하는 것을 지정해서 사용할 수 있음.
    • 하지만 해당 객체를 사용하는 클라이언트 쪽 코드가 지저분해짐.
  • @Primary(권장)

 

같은 타입의 빈이 모두 필요할 경우

AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext();
Map<String, MemberRepository> beansOfType = ac.getBeansOfType(MemberRepository.class);

 

빈 생명주기 콜백

데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요함.

스프링은 객체를 생성하고 의존관계 주입이 완료되면 콜백 메서드를 통해서 초기화 시점을 알려줌. 물론 스프링 컨테이너가 종료되기 직전에 소멸 콜백 또한 줌.

 

스프링 빈의 이벤트 라이프사이클

스프링 컨테이너 생성 → 스프링 빈 생성 → 의존관계 주입 → 초기화 콜백 → 사용 → 소멸 전 콜백 → 스프링 종료

 

** 객체의 생성과 초기화는 분리하는 것이 좋음

  • 생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가짐.
  • 반면에 초기화는 이렇게 생성된 값들을 이용해서 외부 커넥션을 연결하는 등 무거운 동작을 수행(물론 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우에는 생성자에서 한번에 다 처리하는게 나을 수 있음.
    → 따라서 생성자 안에서 무거운 초기화 작업을 함께 하는 것보다는 객체를 생성하는 부분과 초기화하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋음

스프링에서 지원하는 빈 생명주기 콜백

  • 인터페이스(InitializingBean, DisPosableBean) 구현
    • 스프링 전용 인터페이스기 때문에 스프링에 의존
    • 초기화, 소멸 메서드의 이름을 변경할 수 없음.
    • 내가 코드를 고칠 수 없는 외부 라이브러리에 적용 불가
  • 설정 정보(ex AppConfig)에 초기화 메서드, 종료 메서드 지정
    • 메서드 이름을 자유롭게 줄 수 있음.
    • 스프링에 의존하지 않음
    • 코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있음
      • 종료 메서드 추론
        • destroyMethod의 기본 값이 (inferred)인데 이 설정은 라이브러리 대부분이 사용하는 종료 메서드 이름인 close, shutdown을 찾아서 호출
        • 추론 기능을 사용하기 싫을 때는 destroyMethod=”” 처럼 빈 공백을 지정하면 됨.
  • @Bean(initMethod = "init", destroyMethod = "close") 처럼 초기화, 소멸 메서드를 지정 가능
  • @PostConstruct, @PreDestroy 어노테이션 지원(권장)
    • 최신 스프링에서 가장 권장하는 방식
    • 어노테이션 하나만 붙이면 되므로 매우 편리
    • 자바 표준이라 다른 컨테이너에서도 잘 동작
    • 컴포넌트 스캔과 잘 어울림(이건 왜인지 아직 모름)
    • 유일한 단점은 외부 라이브러리를 적용하지 못한다는 것! 외부 라이브러리를 초기화, 종료해야 하면 @Bean의 기능을 사용하자!

빈 스코프

스프링은 다음과 같은 다양한 스코프를 지원

  • 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 스코프
  • 프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프. 해당 빈을 요청할 때마다 새로운 객체를 생성해서 넘겨줌.
  • 웹 관련 스코프
    • request: 웹 요청이 들어오고 나갈 때까지 유지되는 스코프
    • session: 웹 세션이 생성되고 종료될 때까지 유지되는 스코프
    • application: 웹의 서블릿 컨텍스트(?)와 같은 범위로 유지되는 스코프
    • webspcket: 웹 소켓과 동일한 생명주기를 가지는 스코프

의존하는 객체를 주입받아야 생성할 수 있다. 하지만 Request 스코프인 객체를 주입받아야 하는 객체의 경우 Request가 왔을 때만 생성할 수 있기 때문에 여기서 오류가 발생한다.

해결방법

  • ObjectProvider
  • proxy(권장)
    • @Scope(proxyMode = ScopeProxyMode.TARGET_CLASS)를 설정하면 가짜 객체를 주입해서 클라이언트 객체를 생성하고 Request가 왔을 때마다 진짜 객체를 요청