📙 SpringFramework 등장배경

Framework VS Library

프레임워크는 귀찮은 작업을 줄이기 위해 만들어짐

SpringFramework 등장 배경 2

EJB란? (Enterprisee JavaBeans)

• EJB는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉, EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다.
• EJB 사양은 Java EE의 자바 API 중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고 EJB는 업무 로직을 처리하는 역할을 한다.

EJB - 현실에서의 반영이 어렵다.

• 코드 수정 후 반영하는 과정 자체가 거창해 기능은 좋지만 복잡한 스펙으로 인한 개발의 효율성이 떨어짐

SpringFramework 등장 배경3

• 웹 사이트가 점점 커지면서 엔터프라이즈급의 서비스가 필요하게 됨
• 자바 진영에서는 EJB가 엔터프라이즈급 서비스로 각광을 받게 됨
  • EJB 스펙에 정의된 인터페이스에 따라 코드를 작성하므로 기존에 작성된 POJO를 변경해야 함
  • 컨테이너에 배포를 해야 테스트가 가능해 개발 속도가 저하됨
  • 배우기 어렵고, 설정해야 할 부분이 많음

Rod Johnson이 EJB를 사용하지 않고 엔터프라이즈 어플리케이션을 개발하는 방법을 소개함( 스프링의 모태 )

• AOP나 DI같은 새로운 프로그래밍 방법론으로 가능
• POJO로 선언적인 프로그래밍 모델이 가능해 짐

SpringFramework 등장 배경 4

점차 POJO + 경량 프레임워크를 사용하기 시작
POJO (Plain Old Java Object) - 옛날 자바의 객체를 유지

• 특정 프레임워크나 기술에 의존적이지 않은 자바 객체
• 특정 기술에 종속적이지 않기 때문에 생산성, 이식성 향상
• Plain : component interface를 상속받지 않는 특징 (특정 framework에 종속되지 않는)
• Old : EJB 이전의 java class를 의미

경량 프레임워크

• EJB가 제공하는 서비스를 제공해 줄 수 있는 프레임워크 등장
• Hibernate(JPA), JDO, myBatis, Spring

SpringFramework 등장 배경 5

POJO + Framework

• EJB서버와 같은 거창한 컨테이너가 필요 없다.
• 오픈 소스 프레임워크라 사용이 무료
• 각종 기업용 어플리케이션 개발에 필요한 상당히 많은 라이브러리가 지원
• 스프링 프레임워크는 모든 플랫폼에서 사용이 가능하다.
• 스프링은 웹 분야 뿐만이 아니라 어플리케이션 등 모든 분야에 적용이 가능한 다양한 라이브러리를 가지고 있다.

Spring Framework? = 경량화 된 솔루션이다.

• 기존의 자바의 무거웠던 부분을 최소화함
• JEE를 대체하는 Framework이다.
• DI(Dependency Injection) 나 AOP(Aspect Oriented Programming)와 같은 기능도 지원 한다.

📙 StringFramework의 특징

1) 경량적이다.

스프링은 여러 개의 모듈로 구성되어 있는 모듈식 프레임워크이다. 각 모듈은 하나 이상의 JAR 파일로 구성되어 있어 쉬운 개발과 실행이 가능하다. 또한 POJO(평범한 옛날 자바 객체, Plain Old Java Object) 형태로 객체를 관리해서 단순하고 가볍다.

2) 제어의 역행(IoC, Inversion of Control)과 의존성 주입(DI, Dependency Injection)

스프링은 IoC를 통해 애플리케이션을 구성하는 객체 간의 낮은 결합도를 유지한다. IoC는 말 그대로 개발자가 직접 생성하거나 제어하는 것이 아닌 스프링의 Spring Bean모듈에서 객체를 생성하고 제어하며 관리하는 특징을 잘 설명해준다. (Bean 인스턴스를 생성해주는 곳은 Bean Factory라고 불린다.)

// 기존 Java
public class TV {
	private Speaker speaker;
    
    public TV(Speaker speaker) {
    	this.speaker = speaker;
    }
}

// Spring
@Component
public class TV {
	
    @Autowired
	private Speaker speaker;
}

DI는 객체 간의 의존성을 크게 줄여준다는 것에서 의미가 있다. 객체 간의 의존성이 줄어든다는 것은 그만큼 유지 보수를 할 때 손이 많이 가는 것을 줄여준다는 의미이기도 하다.

3) 관점 지향 프로그래밍(AOP, Aspect Oriented Programming)

스프링은 비즈니스 메서드를 개발할 때 사용하는 공통 로직을 외부의 독립된 클래스로 분리하여, 해당 기능을 프로그램 코드에 직접 명시하지 않고 선언적으로 처리할 수 있다. 이로 인해 응집도가 높은 비즈니스 컴포넌트를 만들 수 있으며, 유지 보수 또한 높일 수 있다. OOP의 문제점 또한 보완할 수 있다.

4) 컨테이너(Container)

컨테이너는 특정 객체의 생성과 관리를 담당하고 객체 운용에 필요한 다양한 기능을 제공한다. 대표적으로 Servlet과 Servlet Container가 그 예인데, Servlet 객체를 생성하고 생명 주기를 관리해주는 게 Servlet Container라는 맥락에서 스프링 또한 애플리케이션의 운용에 필요한 객체의 생성과 의존 관계를 관리한다는 점에서 일종의 컨테이너라고 할 수 있다.

📙 StringFramework의 구조

Spring 삼각형

POJO

1. PSA (Portable Service Abstraction)

• 환경의 변화와 관계없이 일관된 방식의 기술로의 접근 환경을 제공하는 추상화 구조를 말함
• 특정 클래스가 추상화된 상위 클래스를 일관되게 바라보며 하위 클래스의 기능을 사용하는 것을 PSA의 기본 개념이다.
• 즉 기존 작성된 코드를 수정하지 않으면서 확장 가능, 어느 특정 기술에 특화되어 있지 않는 코드이다.

2. IoC/DI (Inversion of Control / Dependency Injection)

• IoC(제어의 역행)와 DI(의존성 주입)는 다른 개념
• IoC는 프로그램 제어권을 역전시키는 개념
• DI는 해당 개념을 구현하기 위해 사용하는 디자인 패턴 중 하나로, 이름 그대로 객체의 의존관계를 외부에서 주입시키는 패턴을 말한다.
• 외부에서 객체 만들어서 준걸 내가 가져다가 쓰는거
• DI는 유연하게 확장 가능한 객체를 만들어 두고 객체 간의 의존관계는 외부에서 다이나믹하게 설정

3. AOP (Aspect Oriented Programming)

• 관점 지향 프로그래밍
• 관심사의 분리를 통해서 소프트웨어의 모듈성을 향상
• 공통 모듈을 여러 코드에 쉽게 적용가능

Spring Framework의 동작 과정

📙 IoC & DI & Container

IoC (Inversion of Control) - 제어의 역행

IoC -> 미리 만들어 놓은 거 쓰는 거

IoC 개념1

• 강한 결합을 낮추기 위해 인터페이스 호출 방식 사용

→ 결합도를 낮춤 (loosely-coupling) = 독립적이게 된다.

• 결합도를 낮췄다는 것은 양쪽 다 바꿔야 하는걸 한쪽만 바꿔도 되게 한거임
• 구현 클래스 교체가 용이하여 다양한 형태로 변화가능( 다형성 )
• 하지만 인터페이스 교체 시 호출 클래스도 수정해야 함( 객체 생성관계 의존성은 여전히 존재 )

IoC 개념2

• 객체 간의 강한 결합을 Factory를 통해 결합도를 낮춤
  • 팩토리 호출 방식
  • 팩토리 방식은 팩토리가 구현 클래스를 생성하므로 클래스는 팩토리를 호출
  • 인터페이스 변경 시 팩토리만 수정하면 됨. 호출 클래스에는 영향을 미치지 않음
  • 하지만 클래스에 팩토리를 호출하는 소스가 들어감. 그것 자체가 팩토리에 의존함을 의미한다.
• 객체 간의 강한 결합을 Assembler를 통해 결합도를 낮춤
  • IoC 호출 방식
  • 팩토리 패턴의 장점을 더하여 어떠한 것에도 의존하지 않는 형태가 됨
  • 실행시점(Runtime)에 클래스 간의 관계가 형성이 됨

• Dependency Lookup - 내가 알아서 찾아서 쓸게
• Dependency Injection - 너 어차피 쓸거지? 미리 넣어줄게(내가 찾을 필요가 없다)

Dependency Lookup

• Lookup한 Object를 필요한 타입으로 매번 형변환 해줘야함(불편)

DI (Dependency Injection) - 의존성 주입

Dependency Injection(DI) 의존성 주입 방법들

• Setter Injection (세터 주입)
  • Setter 메소드에 @Autowired 어노테이션을 붙이는 방법입니다.
  • 수정자 주입을 사용하면 setXXX 메서드를 public으로 열어두어야 하기 때문에 언제 어디서든 변경이 가능하다. (단점)
• Constructor Injection (생성자 주입)
  • 클래스의 생성자가 하나이고, 그 생성자로 주입받을 객체가 빈으로 등록되어 있다면  @Autowired를 생략 할 수 있다.
  • 조금 더 옹호하고 권장함.
• Method Injection
• Field-based injection

스프링 의존성 주입 참고자료 : https://ittrue.tistory.com/227

Dependency Injection(DI) 특징

• Test가 용이해진다.
• 코드의 재사용성을 높여준다.
• 객체 간의 의존성(종속성)을 줄이거나 없앨 수 있다.
• 객체 간의 결합도를 낮추면서 유연한 코드를 작성할 수 있다.
  
  
• lookup 코드 안써도 됨, 안에 이미 있으니 내꺼처럼 써도 됨
• Object가 컨테이너의 존재 여부를 알 필요가 없음
• Lookup 관련된 코드들이 Object 내에서 사라짐
• Setter Injection과 Constructor Injection

DI 사용하는 방법

• XML을 사용하는 방법
• Annotation 사용하는 방법
• Java Config

Conatainer

• 객체의 생성, 사용, 소멸에 해당하는 라이프사이클을 담당
• 라이프사이클을 기본으로 애플리케이션 사용에 필요한 주요 기능을 제공

Container 기능

• 라이프사이클 관리
• Dependency 객체 제공
• Thread 관리
• 기타 애플리케이션 실행에 필요한 환경

Container 필요성

• 비즈니스 로직 외에 부가적인 기능들에 대해서는 독립적으로 관리되도록 하기 위함
• 서비스 look up 이나 Configuration에 대한 일관성을 갖기 위함
• 서비스 객체를 사용하기 위해 각각 Factory 또는 Signleton 패턴을 직접 구현하지 않아도 됨
• 기능을 꺼내 쓸 수 있는 Factory도 스프링이 알아서 해준다.
• BeanFactory를 확장해놓은게 ApplicationContext이다.

BeanFactory

• Bean을 등록, 생성, 조회, 반환 관리
• 일반적으로 BeanFactory보다는 이를 확장한 ApplicationContext 사용
• getBean() method가 정의되어 있음

ApplicationContext (BeanFactory를 확장함)

• Bean을 등록, 생성, 조회, 반환 관리기능은 BeanFactory와 같음
• Spring의 각종 부가 서비스를 추가로 제공
• Spring이 제공하는 ApplicationContext 구현 클래스는 여러가지 종류가 있다.