Spring Framework

스프링 프레임워크

• 기존 jsp와 servlet을 이용한 mvc 패턴 구현 시
  • 사용자 요청 → 요청에 따라 메서드 호출(data 추출 후 dto 생성, 전달 → 서비스(비즈니스 로직) → 데이터베이스 → 결과 반환) → path 반환
  • 위와 같은 순서를 거치는데 변하지 않는 과정들이 있다. 이러한 부분들을 설정을 통해 스프링에서는 쉽게 처리할 수 있도록 한다.
  • 또한, 싱글톤으로 객체를 생성했던 서비스 객체, dao 객체 등을 스프링 컨테이너에서 알아서 생성해주고 던져준다.(DI, IoC)
• 스프링이 나오기 이전, EJB(일정한 형식을 갖춘 jar)로 애플리케이션을 작성하였는데, 여러 편리함이 있었지만 불편함도 컸다. 기능은 좋았지만 복잡한 스펙으로 개발 효율성이 떨어지고, 테스트가 불편했다.
• EJB 스펙에 정의된 형식에 따라 POJO를 변경해야하고, 컨테이너에 배포를 해야 테스트가 가능해 개발 속도가 저하됐으며, 배우기 어렵고 설정해야 할 부분이 많은 등의 문제가 있었다.
• 이때, EJB를 사용하지 않고 엔터프라이즈 애플리케이션을 개발하는 방법이 소개되어 스프링의 모태가 되었다.
• 이후 POJO + 경량 프레임워크를 사용하기 시작했다.
• POJO(Plain Old Java Object): 특정 프레임워크나 기술에 의존적이지 않는 자바 객체로 생산성과 이식성이 높다. 순수 자바 객체를 뜻한다. 테스트하기 용이하며, 객체지향 설계를 자유롭게 적용할 수 있다.
• 경량 프레임워크: EJB가 제공하는 서비스를 지원해 줄 수 있는 프레임워크(Hibernate, iBatis, MyBatis, Spring 등)
• 프레임워크: 뼈대, 골격을 제공한다. 자바로 엔터프라이즈 어플리케이션을 만들 때 포괄적으로 사용하는 뼈대를 제공해준다.

스프링 프레임워크 구조

• Spring 삼각형: IoC/DI, AOP, PSA, POJO
• POJO(Plain Old Java Object)
• PSA(Portable Service Abstraction): 환경과 세부 기술의 변경과 관계없이 일관된 방식으로 기술에 접근할 수 있게 해주는 설계 원칙(ex. db에 관계없이 동일하게 적용할 수 있는 트랜잭션 등)
• IoC/DI(Dependency Injection): IoC의 한 방법이 DI. DI는 유연하게 확장 가능한 객체를 만들어 두고 객체 간 의존관계는 외부에서 동적으로 설정
• AOP(Aspect Oriented Programming): 관심사의 분리를 통해 소프트웨어의 모듈성 향상. 공통 모듈을 여러 코드에 쉽게 적용 가능

스프링의 특징

• 경량 컨테이너: 자바 객체를 담고 있는 컨테이너로, 자바 객체의 라이프사이클을 관리
• DI(의존성 주입) 패턴 지원: 설정 파일(xml), Annotation을 통해 객체 간 의존 관계 설정 가능. 의존하고 있는 객체를 직접 생성하거나 검색할 필요가 없음
• AOP 지원: AOP는 문제를 바라보는 관점을 기준으로 프로그래밍하는 기법. 핵심 관심 사항과 공통 관심 사항을 기준으로 프로그래밍 함으로서 공통 모듈을 여러 코드에 쉽게 적용할 수 있도록 함. 스프링은 자체적으로 AOP를 지원.
• POJO 지원: 특정 인터페이스를 구현하거나 클래스를 상속하지 않는 일반 자바 객체를 지원한다.
• IoC(제어의 역전): 객체에 대한 생성과 생명주기 관리가 스프링 컨테이너에 의해 수행된다.
• Spring Core: 핵심 기능. BeanFactory가 핵심.
• Spring Context: BeanFactory 기능 확장

IoC(Inversion of Control)

• 객체 간 연결 관계를 런타임에 결정하는 것으로, 객체 간 관계가 느슨하게 연결된다.
• IoC의 구현 방법 중의 하나가 DI이다.
• 다른 방법으로는 DL(Dependency Lookup)이 있다. JNDI Lookup이 있다.
• DI는 Setter 주입, 생성자 주입, 메서드 주입이 있다.
• Dependency Lookup: 컨테이너가 lookup context를 통해서 필요한 Resource나 Object를 얻는 방식
• Dependency Injection: 컨테이너가 직접 의존 구조를 object에 설정할 수 있도록 지정해주는 방식
  • object가 컨테이너의 존재 여부를 알 필요가 없다.

Container

• 객체의 생성, 사용, 소멸에 해당하는 라이프사이클을 담당
• 라이프사이클을 기본으로 애플리케이션 사용에 필요한 주요 기능을 제공한다.
• 라이프사이클 관리, Dependency 객체 제공, 쓰레드 관리, 환경 제공
• 부가적 기능을 독립적으로 관리하기 위함
• 서비스 lookup이나 configuration에 대한 일관성을 갖기 위함
• 서비스 객체를 사용하기 위해 factory나 singleton 패턴을 직접 구현하지 않아도 된다.
• IoC Container: object 생성과 관계 설정, 사용, 제거 등의 작업을 코드 대신 독립된 컨테이너가 담당하는데, 컨테이너가 제어권을 가지므로 IoC라고 부른다. 스프링 컨테이너를 IoC 컨테이너라고 부르기도 한다. BeanFactory, ApplicationContext가 대표적이다.
• Spring DI Container
  • 객체(빈)들의 생명주기를 관리 → BeanFactory
  • BeanFactory에 여러가지 기능을 추가한 것이 ApplicationContext
  • getBean()을 통해 객체를 얻어온다.
  • 결합도를 낮추는 방식에는 인터페이스, Factory 등이 있다. 하지만 모두 한계 존재.
  • Factory도 결국 Factory 클래스를 의존하게 됨.
  • IoC는 조립기를 통해 결합도를 낮춘다. 런타임에 클래스 간 관계가 형성된다.
  • Spring Container가 외부조립기 역할을 한다.
• 용어 정리
  • Bean: 스프링이 IoC 방식으로 제어하는 오브젝트
  • BeanFactory: 스프링이 IoC를 담당하는 핵심 컨테이너로, 빈을 등록, 생성, 조회, 반환하는 기능을 담당한다.
  • ApplicationContext: BeanFactory를 확장한 IoC 컨테이너로, BeanFactory에 기능을 추가한 것이다.

DI

• 스프링 빈은 기본적으로 싱글톤
• 일반 객체로 만들 경우 scope를 prototype으로 설정해야한다.
• 설정 정보를 만드는 방법에는 XML, Annotation, Java Code 방법이 있다.
• 객체 간의 의존관계를 자신이 아닌 외부 조립기가 수행한다.
• 객체는 인터페이스에 의한 의존 관계만 알고 있으며 구현 클래스의 차이는 알지 못함