Spring

3 분 소요




IoC 컨테이너

IoC(제어의 역전) - 객체간의 결합도를 줄이기 위한 디자인 패턴중의 하나이다.

IoC 컨테이너는 객체들의 생명주기와 객체간의 의존성을 관리한다.
IoC 컨테이너는 BeanFactory 인터페이스를 구현한 ApplicationContext 를 통해 사용된다.
ApplicationContext 는 빈 이라고 불리는 객체들의 라이프사이클, 빈 간의 의존성 등을
관리하며 필요한 시점에 빈을 제공해준다.

한마디로 객체의 생성과 관리를 전적으로 스프링 프레임워크에 맡기는 것이다.


trade-off


장점

  • 객체들 간의 결합도를 낮출수 있다.
    • 유지보수성, 확장성 향상
  • 겍체간의 의존성을 쉽게 변경할 수 있어 테스트에 용이하다.
  • 객체들의 라이프사이클을 맡기고 비즈니스 로직에 집중할 수 있다.


단점

  • 스프링 프레임워크에 대한 러닝커브
  • 직접 객체의 라이프사이클을 관리할 수 없다.


@Autowire


@Component, @ComponentScan


@Environment





Bean

IoC 컨테이너에 의해 생성되고 관리되는 객체를 의미한다. 일반적으로 스프링의 모든 객체를 의미한다.
XML, 어노테이션, Configuration 파일등을 통해 정의되고
ApplicationContext 에 의해 생성되고 빈 간의 의존성을 처리한다.
기본적으로 싱글톤 스코프를 가지고 다음과 같은 다양한 스코프를 지원한다.

  • Singleton : 하나의 Bean 인스턴스만 생성되며, 모든 요청에 대해 같은 인스턴스가 반환
  • Prototype : 요청마다 새로운 Bean 인스턴스가 생성
  • Request : 각 HTTP 요청마다 새로운 Bean 인스턴스가 생성
  • Session : 각 세션마다 새로운 Bean 인스턴스가 생성





DI

IoC 컨테이너가 제공하는 DI 기능으로 객체간의 의존성을 설정하고 관리할 수 있다.
예를들어, A객체가 B객체를 사용할 경우, A가 B객체를 생성하고 관리하는게 아니라
IoC 컨테이너가 B객체를 생성하고, A객체가 B객체를 사용할 수 있도록 주입해준다.
즉, 개발자 직접 처리하는게 아닌 IoC 컨테이너가 자동으로 처리한다.


trade-off


장점

  • 어플리케이션에서 발생하는 객체간의 결합도를 줄일 수 있다.
    • 이를 통해 유지보수, 확장성을 향상시킬 수 있다.
  • 의존성을 주입할 때 인터페이스를 사용해서 의존성 역전 원칙 을 지킬 수 있다.


단점

  • 스프링 프레임워크에 대한 러닝커브
  • 잘못 구현할 경우 객체간의 의존성이 너무 복잡해 질 수 있다.


@Bean Scope





AOP

다양한 관점으로 코드를 모듈화 하고 관심사를 분리하는 것이다.
예를들어, 비즈니스 로직에서 반복적으로 사용되는 공통 기능 (로깅, 트랜잭션, 보안 등) 을
별도의 모듈로 분리하여 관리하고 적용할 수 있다.
즉, 로직과 관련없는 부가적인 관심을 코드에서 분리하여 모듈화 하는 기법이다.

다음과 같은 주요 구성요소로 구성된다.

  • Aspect
    • 특정 관심사를 처리하는 모듈 (모듈화된 로직)
    • 보통 공통으로 적용되는 부가 기능 (로깅, 트랜잭션 처리 등)을 담당한다.
  • Join point
    • 언제나 관심사가 적용될 수 있는 코드 지점 (메서드 호출 등)
  • Advice
    • Aspect 가 Join point 에 적용하는 실제 로직(코드)
    • Before, After, Around 등의 Advice유형 이 있다.
  • Pointcut
    • Join point 중에서 Aspect 가 적용되는 대상(메서드, 클래스 등)을 지정하는 패턴
  • Weaving
    • Aspect 를 대상 코드에 적용하는 과정
    • 스프링에서는 컴파일 타임, 로드 타임, 런타임에 모두 Weaving 이 가능하다.


trade-off


장점

  • 비즈니스 로직과 부가기능의 분리
    • 가독성, 유지보수성 향상
  • 중복되는 부가기능을 한곳에서 관리할 수 있어 중복을 제거할 수 있다.
  • 부가기능이 추가 / 변경 될때, 비즈니스 로직을 수정할 필요가 없다.


단점

  • 복잡성이 증가할 수 있다.
  • 러닝커브
  • 프록시 기반으로 동작하기 때문에 다양한 기능 (final/private 메서드 등) 이 제한될 수 있다.
    • AspectJ 등의 다른 AOP 프레임워크 사용으로 해결 가능





PSA

여러개의 서비스 구현체를 추상화 하여 사용할 수 있도록 일관된 인터페이스를 제공하는 기법이다.
스프링에서는 JDBC, JMS, 캐시, 메일 등 의 서비스에 대해 PSA 를 적용하고 있다.
예를들어, JdbcTemplate 은 JDBC 서비스에 대한 PSA 를 제공하며 클라이언트 코드에서
서비스 구현체를 직접 참조하지 않고, 일관된 방법으로 서비스를 사용할 수 있게 된다.
또한 서비스 구현체를 변경하더라도, 클라이언트 코드가 변경되지 않도록 해주는 역할을 한다.

  • 인터페이스 추상화
    • 서비스를 추상화 하기 위해 인터페이스를 사용
    • 인터페이스는 일반적으로 서비스의 기능을 제공하는 메서드로 구성
    • 인터페이스 추상화 는 서비스 구현체를 추상화 하는데 사용
    • 클라이언트는 인터페이스를 사용하여 서비스를 호출한다.


  • 팩토리 추상화
    • 서비스 구현체를 생성하고 제공하기 위한 일관된 방법을 제공하는 추상화
    • 팩토리 추상화 는 서비스 구현체를 생성하고 관리하는 데 사용
    • 클라이언트는 팩토리를 사용하여 서비스 구현체를 얻을 수 있다.


  • 예외 추상화
    • 서비스에서 발생하는 예외를 일관된 방식으로 처리하기 위한 추상화
    • 예외 추상화 는 서비스에서 발생하는 예외를 처리하기 위한 일관된 방법을 제공하는 데 사용
    • 클라이언트는 예외 추상화를 사용하여 서비스에서 발생하는 예외를 처리할 수 있다.


trade-off


장점

  • 클라이언트는 서비스 구현체를 직접 참조하지 않고, 일관된 방식으로 서비스를 호출할 수 있다.
  • 클라이언트 코드에서 서비스 구현체를 직접적으로 참조하지 않기 때문에, 서비스 구현체가 변경되더라도 클라이언트 코드를 수정할 필요가 없다.
  • 다양한 기술과 프레임워크에서 동일한 인터페이스를 사용하여 서비스를 호출할 수 있도록 한다.
  • 인터페이스 추상화 와 팩토리 추상화 를 통해 서비스를 모듈화할 수 있다.


단점

  • 인터페이스 추상화와 팩토리 추상화 등을 정의해야 하기 때문에 코드의 양과 복잡성이 증가할 수 있다.
  • 특정한 프레임워크에서만 적용될 수 있기 때문에, 표준화가 되어 있지 않은 경우에는 다른 프레임워크나 라이브러리에서는 적용할 수 없다.





댓글남기기

참고