[Spring] Spring Framework란? - (2) Spring의 특징 (역사, IoC/DI)

Web Application 개발에 Spring framework가 주로 활용되는 이유가 있다.
그 이유는 Spring의 특징으로 설명이 될 것이다.

1. Spring의 역사

특징을 살펴보기 전에 Spring의 역사를 되짚어보고자 한다. 역사를 알면 Spring이 아래와 같은 특징을 갖게된 배경에 대해 쉽게 납득할 수 있을 것이다.
Spring Framwork 탄생 이전에 기업들은 Java의 표준 기술로 EJB를 사용하였다. 하지만 이러한 EJB에는 많은 단점들이 있었고, 이러한 단점들을 보완하기 위해 Spring Framework가 등장하였다.

A. EJB(Enterprise Java Beans)란?

EJB는 대규모 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다.
다양한 Platform에서의 제품 독립성을 위해 비즈니스 로직과 시스템 로직을 분산하는 규약을 규정하고 있다.

기업의 IT시스템 규모가 커지면서 많은 트래픽을 빠르고 안정적으로 처리하기 위해 다양한 기술들(트랜잭션, 멀티스레딩, 리소스폴링, 보안 등)이 시스템에 적용되기 시작했다. 이러한 많은 기술들을 적용하여 개발해야했기 때문에 개발 난이도가 높아지기 시작했고, 이를 보완하기 위해 EJB가 탄생하였다.

• Bean : 컨테이너 내에서 미리 생성되어 대기하고 있는 객체

B. EJB의 특징

EJB는 서버 컴포넌트인 하나의 Enterprise Bean으로 나타낼 수 있고, 이러한 Bean은 크게 세 가지로 나뉜다.

1. 세션 빈(Session Bean) : DB연동이 필요없는 영속적이지 않고 비즈니스 로직을 표현하는 Bean. 해당 Bean은 상태유지여부에 따라 다시 Stateful, Stateless로 나뉠 수 있는데, 식별 가능한 고유성 여부에 따라 차이가 있다.
2. 엔티티 빈(Entity Bean) : 데이터베이스의 데이터를 관리하는 Bean.
3. Message-Driven Bean : queue나 listener를 통해 비동기 메세지 형태로 들어온 요청을 받아서 처리하는 Bean

C. EJB의 장단점

위 사진처럼 EJB서버에 EJB Container가 있고, EJB Container가 bean을 type별로 나누어 관리함으로서 아래와 같은 이점을 가질 수 있다.

1. 객체를 미리 생성하여 메모리에 저장함으로서 많은 트래픽에 대한 안정성 지원
2. 컨테이너가 자동으로 트랜잭션 처리를 진행함으로서 안정적인 데이터 조작 가능
3. Bean 사용여부에 따라 자동적으로 활성화 및 비활성화 시킴으로서 효율적인 메모리 사용 가능
4. 기존 EJB 컴포넌트들이 loading되어 컴포넌트의 라이프사이클을 관리하고 보안, 스레딩 등의 서비스를 제공함으로서 개발자는 비즈니스로직 개발에 더욱 집중 가능

하지만 아래와 같은 단점도 있었다.

1. 객체지향적이지 않음 => 복잡한 프로그래밍 모델
2. 특정 환경과 기술에 종속적 => 성능 및 이동성(portablity) 저하
3. 컨테이너 안에서만 동작가능한 구조 => 반복되는 수정-빌드-배포-테스트 과정 => 개발생산성 저하

정리하면,
EJB가 대량 트래픽에 안정적이고, 데이터 처리 또한 안정적으로 할 수 있고, 비즈니스 로직에 집중 가능하다는 장점이 있다.
하지만 복잡한 프로그래밍 모델에 특정 환경과 기술에 종속되어 있어서 성능과 이동성이 저하된다는 치명적인 단점이 있었고,
컨테이너 안에서만 동작이 되기 때문에 개발생산성이 저하된다는 단점 또한 있었다.

D. Spring Framework의 대두

EJB는 안정적이라는 장점이 있지만, 복잡성이 크고 취약한 성능 및 이동성이라는 단점이 있다.

이에 따라 객체지향 원리에 따라 만들어진 Java 언어의 기본 기술에 충실하여 비즈니스 로직을 구현하는
POJO(Plain Old Java Object) 방식으로 돌아가자는 의견들이 나오기 시작했고,

이러한 의견들은 Spring Framework의 기원이 되었다.

2. Spring의 특징

앞서 언급한 것처럼 Spring은 Java언어 기반의 Framework이다. EJB의 단점을 보완하기 위해 대두되었고, Java언어의 POJO방식에 충실하는 Framework이다. POJO를 기반으로 "테스트의 용이성", "느슨한 결합"에 중점을 두고 개발되었다.

A. POJO(Plain Old Java Object)

: 순수한 Java Object를 뜻하는 말

POJO의 특징은 아래와 같다.

1. 특정 규약에 종속되지 않는다.
   : 외부에 의존성을 두지 않고, 순수한 Java로 구성이 가능해야 함.
2. 특정 환경에 종속되지 않는다.
   : 특정 비즈니스 로직을 처리하는 부분에 외부 종속적인 http request, session 등이 활용되는 경우, POJO를 위배한 것으로 볼 수 있다. @Annotation기반으로 설정하는 부분도 엄연히 POJO라고는 볼 수 없다.
   => Spring에서는 어느정도 타협된 부분인 것 같다.

위와 같은 외부종속성을 최대한 배제하는 POJO의 특징을 고려한다면, 복잡한 시스템과 취약한 이동성이라는 단점을 가진 EJB를 보완할 수 있다.

위 사진과 같이 POJO특성을 기반한 Spring의 세 가지 기능이 있다.
이제 세 가지 기능을 하나씩 살펴볼 것이다.

B. IoC/DI

• IoC(Inversion Of Control) : 제어의 역전, Java 객체를 new로 생성하여 개발자가 관리하는 것이 아닌 Spring Container가 생성하여 관리까지 할 수 있도록 객체관리에 대한 모든 권한을 넘기는 것. Spring Framework의 독자적인 특성
• DI(Dependency Injection) : 의존성 주입, Java 외부객체 활용이 필요할 때 객체를 주입받아 활용하는 것 => 외부와 의존성이 줄어들어 코드 테스트에 용이하고, 코드를 확장하거나 변경할 때 영향을 최소화할 수 있음.
• DI의 사례

IEncoder.java

public interface IEncoder {
    String encode(String message);
}

Base64Encoder.java

import java.util.Base64;

public class Base64Encoder implements IEncoder{

    public String encode(String message){
        return Base64.getEncoder().encodeToString(message.getBytes());
    }
}

UrlEncoder.java

import java.io.UnsupportedEncodingException;
import java.net.URLEncoder;

public class UrlEncoder implements IEncoder{

    public String encode(String message){
        try {
            return URLEncoder.encode(message, "UTF-8");
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
            return null;
        }
    }
}

Encoder.java

public class Encoder {

    private IEncoder iEncoder;

    public Encoder(IEncoder iEncoder){
        this.iEncoder = iEncoder;
    }

    public String encode(String message){
        return iEncoder.encode(message);
    }
}

위 예시는 IEncoder라는 인터페이스를 상속받은 Base64Encoder, UrlEncoder 객체를 주입받아 사용하는 Encoder의 사례를 코드로 표현한 예시이다.

경우에 따라서 여러 인코더를 사용할 수가 있는데, 필요할 때마다 그에 맞는 인코더 객체를 new로 생성하여 활용한다면 코드 복잡성이 증가한다.
=> 이를 보완하기 위해 IEncoder라는 인터페이스를 만들고, 해당 인터페이스를 상속받아 각 유형의 Encoder(Base64Encoder, UrlEncoder)를 위 코드와 같이 추상화 시킨다면 정해진 규격의 타입으로 통일시킬 수 있어서 복잡성을 줄일 수가 있다. 또한, DI개념을 도입하여 Encoder라는 객체주입용도의 base class를 추가하고 다양한 유형의 Encoder를 하나의 base class 객체에 주입해서 사용한다면, 코드의 재사용성이 증가하여 테스트를 용이하게 할 수 있고 Encoder라는 base class를 건드리지 않아도되기 때문에 기능 확장성 또한 좋아진다.

• IoC의 사례

IocApplication.java

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@SpringBootApplication
public class IocApplication {

    public static void main(String[] args) {
        SpringApplication.run(IocApplication.class, args);
        ApplicationContext context = ApplicationContextProvider.getContext();

        //Base64Encoder base64Encoder = context.getBean(Base64Encoder.class);
        //UrlEncoder urlEncoder = context.getBean(UrlEncoder.class);

        Encoder encoder = context.getBean("urlEncode", Encoder.class);
        String url = "www.naver.com/books/it?page=10&size=20&name=spring-boot";
        String result = encoder.encode(url);
        System.out.println(result);
    }

}

@Configuration
class AppConfig{

    @Bean("base64Encode")
    public Encoder encoder(Base64Encoder base64Encoder){
        return new Encoder(base64Encoder);
    }

    @Bean("urlEncode")
    public Encoder encoder(UrlEncoder urlEncoder){
        return new Encoder(urlEncoder);
    }
}

Base64Encoder.java

import org.springframework.stereotype.Component;

import java.util.Base64;

@Component("base74Encoder")
public class Base64Encoder implements IEncoder {

    public String encode(String message){
        return Base64.getEncoder().encodeToString(message.getBytes());
    }
}

UrlEncoder.java

import org.springframework.stereotype.Component;

import java.io.UnsupportedEncodingException;
import java.net.URLEncoder;

@Component
public class UrlEncoder implements IEncoder {

    public String encode(String message){
        try {
            return URLEncoder.encode(message, "UTF-8");
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
            return null;
        }
    }
}

ApplicationContextProvider.java

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.stereotype.Component;

@Component
public class ApplicationContextProvider implements ApplicationContextAware {

    private static ApplicationContext context;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        context = applicationContext;
    }

    public static ApplicationContext getContext(){
        return context;
    }
}

DI 사례의 코드에서 객체는 여전히 Spring Container가 아닌 개발자에 의해 new로 생성되고 관리가 되고있는 코드이다.
IoC(제어의 역전)개념을 적용하여 객체 관리의 주체를 Spring Container에 넘기기 위해서는 객체가 Spring Container에 생성되고, Container에 의해 객체가 주입되도록 별도의 설정이 필요하다. 이러한 설정은 @Annotation형태의 어노테이션으로 이루어진다.

• 어노테이션이란? 사전적 의미로는 주석이라는 뜻을 가지고 있고, Java에서의 어노테이션은 코드상에 추가하여 application이 코드를 어떻게 처리해야하는 지를 알려주기 위한 추가 데이터이다.

위 IoC 코드와 DI 코드의 차이를 잘 살펴보면, Encoder 각 클래스에 @Component라는 어노테이션이 추가 기입되어 있고 Spring Container로부터 객체를 받아오기 위해 ApplicationContextProvider.java 코드를 추가하였다. 또한, 메인함수에서 Spring Container 주체적으로 객체주입을 통해 객체를 생성할 수 있도록 Bean을 생성하는 코드를 추가하였다.

• Bean이란? 위 EJB에서 언급한 것처럼 Container상에서 생성하고 관리하는 Java 객체이다.

@Component라는 어노테이션을 붙임으로서 해당 클래스의 객체가 Spring Container에서 생성되고 관리될 수 있도록 설정되었다. 그리고 Spring Container상에서 생성된 객체를 가져오기 위해 ApplicationContextAware클래스를 상속받은 ApplicationContextProvider클래스를 생성하였고, 해당 클래스의 getContext().getBean()메소드를 활용한다면 생성된 Bean을 가져올 수 있다. 마지막으로 메인클래스에 @SpringBootApplication어노테이션을 추가하여 Spring Boot Framework로 프로젝트가 관리될 수 있도록 하였고, Bean설정을 추가하여 Spring Container가 객체주입을 통해 Bean을 생성할 수 있도록 하였다.

이를 통해 객체의 생성과 관리의 역할은 개발자가 아닌 Spring Container가 맡게 되었다. 이것이 IoC(제어의 역전)이다.

이어서

Spring Framework 삼각형에서 나타나는 대표적인 특징인 AOP와 PSA에 대해 알아볼 것이다.