토비의 스프링#1 오브젝트와 의존관계

# 스프링이란 무엇인가?

2004년에 등장한 자바 엔터프라이즈 앱 개발에 사용되는 프레임워크. 스프링은 단순히 한 회사가 돈을 벌기 위해 만들어진 도구가 아니다. 오래전부터 자바 엔터프라이즈 시스템을 개발해오고 연구해온 수 많은 사람들의 경험이 집약된 결정체이다. 순수한 자바 코드(POJO, Plain Old Java Object)를 추구한 단순함과 결합도와 의존성을 낮춰 서비스를 추상화하고, 수많은 도구들과 함께 사용할 수 있는 유연성을 제공한다.

 

• 앱의 기본 틀 제공 - 스프링 컨테이너
  컨테이너 또는 앱 컨텍스트라고 불리는 런타임 엔진을 제공한다. 스프링은 개발자의 설정 정보를 바탕으로 서블릿이나 서비스 객체를 컨테이너에 등록해서 사용한다. (독립적으로 동작할 수 있지만 보통 웹 모듈에 사용한다.)
  
  
• 프로그래밍 모델 프레임워크화
  스프링은 세가지 핵심 프로그래밍 모델을 지원한다.
  1. IoC/DI라 불리는 오브젝트의 생명주기와 의존관계 모델
  2. 서비스의 추상화. 특정 서버, 기술에 종속되지 않고 이식성이 뛰어난 앱을 만듬.
  3. AOP. cross-cutting cocern을 모듈로 독립화하는 기술
  
  
• 기술 API
  현업에서 사용하는 거의 모든 기술에 대해 API와 서비스를 제공한다. https://spring.io/

Spring makes Java simple.

 

---

# 오브젝트와 의존관계

 

@ 기존의 방식

스프링은 자바를 기반으로 한 기술이다. 자바와 스프링 둘 다 가장 중요하게 가치를 두는 것은 바로 '객체'이다. 옛 방식으로 사용자 정보를 JDBC API를 이용한 DAO(Data Access Object, DB를 담당하는 객체)를 만들어보자.

// User 객체. 이제 UserDAO를 만들어보자
@Getter @Setter
public class User {
    String id;
    String name;
    String password;
}

 

이 객체를 DB 테이블로 구성하면 아래와 같을 것이다.

필드명	타입	설정
Id	VARCHAR(10)	PK ( Primary Key )
Name	VARCHAR(20)	NN ( Not Null )
Password	VARCHAR(20)	NN

 

이를 MySQL등을 사용해서 구현한다면 아래와 같은 CREATE TABLE 명령을 실행하면 된다.

create table users{
    id varchar(10) primary key,
    name varchar(20) not null,
    password varchar(10) not null
}

자 이제 이 두개를 JDBC API를 이용해 사용자 정보를 DB에 저장하는 UserDao 클래스를 만들어보자.

• DB 연결을 위한 JDBC Connection을 가져온다
• SQL을 담은 Statement 객체를 생성한다.
• 만들어진 Statement 객체를 실행한다
• 조회의 경우 SQL 실행 결과를 ResultSet에 받아 객체에 옮겨준다.
• 작업중에 생성된 리소스는 작업을 마친후 반드시 반환해야한다.
• JDBC API가 만들어내는 예외를 처리한다. 단 예외가 발생한 시점에 따라 다르게 처리해주어야한다.

public class UserDao {
// 예외처리는 예제에서는 하지않았다. 하지만 실제 코드에서는 상황에 따라 다 처리해주어야한다.

    public void add(User user) throws ClassNotFoundException, SQLException {
        Class.forName("com.mysql.jdbc.Driver");
        Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/myDB", "id", "password");

        String query = "insert into users(id, name, password) value(?,?,?)";
        PreparedStatement ps = conn.prepareStatement(query);
        ps.setString(1, user.getId()); // 변수 지정
        ps.setString(2, user.getName());
        ps.setString(3, user.getPassword());

        ps.executeUpdate(); // 쿼리 실행
        ps.close();
        conn.close();
    }
    
    
    public User get(String id) throws ClassNotFoundException, SQLException {
        Class.forName("com.mysql.jdbc.Driver");
        Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/myDB", "id", "password");

        String query = "select * from users where id = ?";
        PreparedStatement ps = conn.prepareStatement(query);
        ps.setString(1, id);
        ResultSet rs = ps.executeQuery();

        User user = new User();
        rs.next(); // 여러 개일 경우 while(rs.next());
        user.setId(rs.getString("id"));
        user.setName(rs.getString("name"));
        user.setPassword(rs.getString("password"));

        rs.close();
        ps.close();
        conn.close();

        return user;
    }
}

제법 복잡해 보이는 코드가 만들어졌다. 이 코드가 제대로 동작하는지 확인하려면 어떻게 해야할까?

• 웹 앱을 실제 서버에 띄워 DB 쿼리를 날려본다 => 테스트치고는 비용이 너무 큰데?
• 작동할 것이라 믿고 기도한다. => 진심으로?
• main 메서드에 DAO객체를 만들어 콘솔창에 찍어본다.

    public static void main(String[] args) throws ClassNotFoundException, SQLException {
        UserDao dao = new UserDao();

        User user = new User();
        user.setPassword("pw");
        user.setName("name");
        user.setId("id");

        dao.add(user);

        // 음! 잘 동작하는 구만!
        System.out.println("[insert 성공] user = " + user.getId());
        
    }

이 방법에는 정말, 정말 많은 문제들이 숨어있다. 만약 실제 개발자가 이러한 코드를 작성했다면 개발팀에 서바로 쫓겨나지 않을까 싶다. 이를 객체지향적인 코드로 개선해나가며, 스프링에서 사용하는 방법이 무엇인지 알아보자.

• 객체를 생성하고, 로직을 실행하고, 객체를 회수하는 등 너무 많은 책임을 한 객체가 지니고 있다.
• main 스레드 하나로 모든 테스트를 관리하고 있다.
• 코드를 간단하게 수정해도 앱 전체에 영향을 미칠 수 있다.
• 로그를 콘솔에 찍고 있다. 비용이 크고 Thread-Safety하지 않다.
• 일부분만 쪼개서 단위로 테스트할 수 없다.

 

---

@ 개선1. 관심사의 분리(Separation of Concerns)

UserDao에서는 [DB커넥션을 만들고, 회수하는 설정부분]과 직접 [User 객체에 데이터를 저장하는 실행부분]이 하나로 합쳐져있다. 이 두 관심사를 분리시키고 모듈화하여 반복되는 코드를 줄여보자.

• 관심사1. DB 연결을 하기 위한 커넥션
• 관심사2. 사용자 등록을 위한 SQL 문장 (Statement 객체)를 만들고 실행하기
• 관심사3. 작업이 끝나고 난 후 DB 커넥션 자원의 회수 

이렇게 위 아래로 반복되는 설정부분을 Cross-Cutting Corcern (또는 공통관심사항)이라고 부른다.

    public Connection getConnection() throws ClassNotFoundException, SQLException {
        Class.forName("com.mysql.jdbc.Driver");
        Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/myDB", "id", "password");
        return conn;
    }
    
    public User get(String id) throws SQLException, ClassNotFoundException {
        Connection c = getConnection();
        // 이하 코드 생략
    }

 

여기서 한걸음 더 나아가 사업이 커지면서 N사와 D사의 사용자관리를 동시에 맡게 되었다고 상상해보자. 이제 UserDao는 각 회사마다 다른 DB를 통합해서 사용해야한다. 어떻게 확장할 수 있을까?

추상화와 상속을 사용하면 된다!

public abstract class UserDao{ 
	...
    // 추상클래스로 만들었다.
   	public abstract Connection getConnection() throws ClassNotFoundException, SQLException;
}


public class DUserDao extends UserDao {
    @Override
    public Connection getConnection() throws ClassNotFoundException, SQLException {
        Class.forName("N사의 DB 커넥션 생성");
        Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/myDB", "id", "password");
        return conn;
    }
}


public class NUserDao extends UserDao {
    @Override
    public Connection getConnection() throws ClassNotFoundException, SQLException {
        Class.forName("D사의 DB 커넥션 생성");
        Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/myDB", "id", "password");
        return conn;
    }
}

 

참고로 이런 형태를 사용하는 코드를 템플릿 메서드, 팩토리 메서드 패턴이라고 부른다.

UserDao에 팩토리 메소드 패턴을 적용해서 getConnection()의 관심사를 분리하는게 좋을 것 같아요

• 템플릿 메서드 패턴 (Template method pattern)
    부모에서 기본적인 메서드를 정의하고, 세부적인 메서드를 추상메서드로 둬 자식이 구현해 사용하는 방식
    모든 객체가 공통적으로 사용하는 동작을 부모(템플릿)를 통해 추상화(인터페이스 화) 시키는 것.
  

  

  '템플릿'이 아닌 '템플릿 메서드' 패턴인 이유. 반복 or 공통된 동작을 추상화시키자!

  
  
  
• 팩토리 메서드 패턴 (Factory method pattern)
   객체 생성 방법(팩토리 클래스의 역할)을 서브클래스에 위임하여 캡슐화 하는 것 (슈퍼클래스는 관심 X)
    참고로 자바에서는 오브젝트를 생성(new)하는 객체나 메서드를 '팩토리 객체 or 메서드'라고 부른다. 
    팩토리 메서드를 구현할 때 주로 사용하는 방법이라 이런 이름이 붙은 것. [팩토리 메서드 == 패턴] 아님!
  

  

  아래 예제를 보면 쉽게 이해할 수 있다. ConcreteCreator == IDCardFactory

// 팩토리 메서드 패턴의 사용예제

// 구체적인 생성방법을 서브클래스에 캡슐화한다. (부모는 관심X)
Factory factory = new IDCardFactory();

Product card1 = factory.create("홍길동"); // factory 인터페이스로 Product의 구현체를 만든다.
Product card2 = factory.create("이순신"); // 구체적인 생성방법은 factory의 서브클래스가 담당.
Product card3 = factory.create("강감찬"); // Product card3 = new IDProduct("id")
card1.use();
card2.use();
card3.use();

abstract class Factory {
    public final Product create(String owner) {
        Product p = createProduct(owner); // 객체생성 방법은 서브클래스가 결정
        registerProduct(p);
        return p;
    }
    protected abstract Product createProduct(String owner);
    protected abstract void registerProduct(Product p);
}


class IDCardFactory extends Factory {
    @Override
    protected Product createProduct(String owner) { return new IDCard(owner); }
    // .. 이하 구현부 생략
}


class AdminCardFactory extends Factory {
    @Override
    protected Product createProduct(String owner) { return new IDCard(owner); }
	// .. 이하 구현부 생략
}

 

---

@개선2 무지는 우리의 무기. 인터페이스를 통한 분리

객체가 서로를 몰라도 사용할 수 있게 분리시켜 버리자. 즉 한 객체를 변경했을 때 변경이 확산하는 것을 막자.

다만 인터페이스를 사용해도 결국 언젠가는 '구현체'를 연결해야한다. 설정작업은 분리할 수 없다. 수정은 불가피하다.

// 인터페이스를 통해 결합도(의존관계)를 유연하게 만들었다.
interface MemberRepository{...}
interface DiscountPolicy{...}

Class MemoryMemberRepository implement MemberRepository{...}
Class FixDiscountPolicy implement DiscountPolicy{...}

// 하지만 인터페이스를 사용했다고 한들, 결국 언젠가는 구현체를 직접 연결해주어야 한다.
// 구현체가 바뀐다면? 기존의 생성 & 설정 코드를 변경해야한다. 전혀 상관없는 객체라고 하더라도
private final MemberRepository memberRepository = new MemoryMemberRepository();
private final DiscountPolicy discountPolicy = new FixDiscountPolicy();

 

---

@개선3. 관계, 설정 책임의 분리

그럼 아예 [객체를 생성, 설정하는 영역]과 [로직 실행영역]을 분리할 수는 없을까?

-> 의존성 주입(DI, Dependency Injection), 구현체는 니가 알아서 넣어라. 난 인터페이스만 의존해서 사용하겠다.

public class OrderService {
    // 사용하는 객체에서는 구현체를 생성, 설정하지 않는다.
    public final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    // 니가 알아서 객체 생성해서 넣으렴. 난 인터페이스만 보고 사용합니다.
    public MemberServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
 }

컨테이너에 관리되는 객체를 스프링에서는 스프링 빈(Bean)이라 부른다.

// 객체 생성, 즉 의존성 주입을 담당하는 '설정'을 담당하는 객체
// 이를 IoC 컨테이너, DI 컨테이너라고도 부른다.
public class AppConfig { 
    // Repository
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
 
    // DiscountPolicy
    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
    
    // OrderService
    public OrderService orderService() {
        return new OrderServiceImpl(
                  this.memberRepository(),
                  this.discountPolicy()
                );
    }
}

이런식으로 코드를 작성한 것을 전략패턴이라고 한다.

• 전략 패턴(strategy pattern)
  정책(Policy) 패턴이라고도 하며 알고리즘(구현체)을 필요에 따라 전략적으로 변경할 수 있게 하는 패턴.
  즉 실행흐름(Context)에서 아예 특정부분을 클래스(Startegy)로 분리시켜 확장성과 다형성을 구현한 것.
  

  

  클라이언트(Context)는 인터페이스(Startegy)에만 의존하기에 가능한 패턴

    public interface DiscountPolicy { // 인터페이스만 의존하도록 클라이언트를 설계.
    	double calculateWithDisCountRate(Item item);
    }
    
    // 필요한 알고리즘을 상황에 맞춰 선택 
    public class FirstCustomerDiscount implements DiscountPolicy{
    	@Override // 방법1.
    	public double calculateWithDisCountRate(Item item) {
    		return item.getPrice() * 0.9;
    	}
    }
    
    public class LastCustomerDiscount implements DiscountPolicy{
    	@Override // 방법2.
    	public double calculateWithDisCountRate(Item item) {
    		return item.getPrice() * 0.8;
    	}
    }
    
    public class UnFreshFruitDiscount implements DiscountPolicy{
    	@Override // 방법3.
    	public double calculateWithDisCountRate(Item item) {
    		return item.getPrice() * 0.8;
    	}
    }

---

@개선4. 제어의 역전(IoC)

이는 @개선3과 동시에 진행되었다. 기존의 코드에서는 설정부분 (객체를 생성, 의존성 주입, 반환)부터 프로그램이 실행되고 종료되는 메인스레드의 흐름까지 우리가 직접 조종하였다.

 

하지만 관심사를 분리하고 의존성을 주입받는 방법을 사용해서, 이제 더 이상 객체는 프로그램의 실행과정에 영향을 끼치지 않는다. 단지 '객체'가 맡은 책임에 따라 데이터를 가지고 로직을 실행할 뿐이다. 객체는 앱 실행의 제어권을 가지고 있지 않다. 이렇게 프로그램의 제어 흐름 구조가 뒤바뀌는 것을 제어의역전(IoC, Inverse of Control)이라고 한다.

 

사실 제어의 역전개념은 과거부터 폭넓게 적용되어 있었다. 자바의 서블릿을 생각해보자. 일반적으로 프로그램은 main()메서드를 통해 개발자가 직접 앱의 제어권을 가진다. 하지만 서블릿을 통한 개발은, 개발자는 서블릿 객체의 책임을 정하고 그 책임에 맞는 비즈니스 로직을 구현할 뿐이다. 이 객체가 언제 어디서 사용될지 프로그램이 어떻게 실행되는지는 개발자가 알 수 없다. WAS가 담당할 뿐. 제어권이 역전되어있다.

 

스프링에서는 제어의 역전을 이렇게 설정 컨테이너(AppConfig 객체)가 의존성 주입을 주입하는 방법으로 구현한다. 그래서 범용적인 단어인 [IoC 컨테이너] 대신에 의미를 명확하게 할려고 의존성 주입(DI, Dependency Injection) [DI 컨테이너]라는 용어를 사용한다. 이 두개는 같은 컨테이너를 의미한다.

 

---

# 오브젝트 팩토리를 이용한 스프링 IoC

@ Application Context와 설정정보

이제 스프링에서 이를 어떻게 활용하는지 알아보자. 스프링에서는 직접 만들고 관계를 부여받는 객체들을 스프링 빈(Bean)이라고 부른다. 옛날에 엔터프라이즈 자바빈(EJB)에서 사용한 객체단위의 컴포넌트와 비슷한 의미로 사용된다.

 

즉 스프링 빈은 앱에서 사용되는 컴포넌트이면서 스프링 컨테이너(DI 컨테이너)가 객체생성, 의존관계설정, 사용등을 제어해주는 IoC가 적용된 오브젝트를 가르키는 말이다. 스프링에서는 이러한 생성, 관계설정을 담당하는 IoC 객체를 빈 팩토리(Bean Factory)라고 부른다. 

 

하지만 BeanFactory를 직접 사용하는 경우는 없다. 이를 상속한 ApplicationContext를 스프링 컨테이너로 사용한다. BeanFactory에서는 위에서 설명한 IoC와 객체생성, 설정부분이 정의되어있다면 ApplicationContext는 이를 포함한 더 다양한 기능들을 가지고 있다. 실제 사용할 때에는 아래와 같이 필요한 스프링빈을 불러와 사용하면 된다.

// 참고로 설정객체(AppConfig) 또한 스프링 컨테이너에 스프링 빈으로 등록해서 사용한다.
ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);

// 스프링 컨테이너는 key-map 구조로 문자열로 구분하여 등록된다.
// UserDao 타입의 "userDao"라는 이름을 가진 스프링 빈을 주입받는 코드.
UserDao dao = context.getBean("userDao", UserDao.class);

// Object.class 는 해당 클래스의 정보를 넘겨주어 필요할 떄 객체 생성을 가능하게 만들어준다.
// 이러한 기술을 자기자신의 설계도(class)를 복제해서 넘기는, 리플렉션 기술이라고 부른다.
// 객체를 문자열("userDao")로 구분지어 사용할 수 있는 이유도 이러한 리플렉션 기술 덕분이다.

참고로 BeanFactory와 App..Context는 인터페이스이다. 구현체가 아니다. 이는 [컨테이너] 자체도 유연하게 변경할 수 있게 만든 것이다.

 

App..Context의 구현체를 어노테이션(AnnotationConfigApp...Context)로 정했으니, 우린 어노테이션을 사용하여 스프링에서 설정정보를 지정할 수 있다. 컨테이너 설정정보를 담는 객체에 @Configuration 태그를 달면된다. 위에서 말했지만 이 객체(AppConfig) 또한 스프링 빈으로 스프링 컨테이너에 등록된다.

 

그리고 우리가 사용할 객체들을 @Bean 메서드를 통해 생성하면 된다. @Bean 태그는 메서드에만 적을 수 있으며 해당 메서드가 반환한 객체를 스프링 컨테이너에 스프링 빈으로 등록한다.

@Configuration
public class AppConfig {
    @Bean // 이름을 지정하지 않으면 반환 객체 이름인 "memberRepository"로 자동설정된다.
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
 
    @Bean(name="myCustomBean") // 물론 이렇게 지정할 수 있으나, 거의 사용하지 않는다.
    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
    
    @Bean // ["orderService", OrderService.class] 를 가진 스프링 빈이 생성됨.
    public OrderService orderService() {
        return new OrderServiceImpl(
                this.memberRepository(),
                this.discountPolicy());
    }
}

 

재밌는 점은 @Configuration 같은 태그가 없더라도 @Bean으로 스프링빈을 등록할 수 있다는 점이다. 그럼 해당 태그는 왜 적는걸까? 그냥 헷갈리지말라고 적는걸까? 당연히 아니다. @Configuration은 해당 객체가 설정객체(AppConfig)임을 스프링에게 알려서, 싱글톤을 구현할 수 있게 만들어준다.

 

싱글톤은 같은 객체가 1번만 생성되도록 만들어서 돌려쓰는 것을 말하는데, 아래의 예제 코드를 보면 이해가 쉽다. 아래와 같이 @Configuration 없이 생성하게되면 동일한 객체를 스프링빈으로 여러번 중복해서 등록하게 된다.

public class AppConfig {
    @Bean
    public MemberService memberService() {
        // MemberService객체는 빈으로 1번 생성됨, Repository() 를 호출해서 의존성 연결
        System.out.println("call AppConfig.memberService");
        return new MemberServiceImpl(memberRepository());
    }
    
    @Bean
    public OrderService orderService() {
        // OrderSerivce 객체는 빈으로 1번 생성됨. Repository()를 호출해서 의존성 연결
        System.out.println("call AppConfig.orderService");
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
 
    @Bean
    public MemberRepository memberRepository() {
        // ?? 여러번 호출했는데 그럼 나는 스프링 빈으로 몇개를 중복해서 가지고있는거야?
        return new MemoryMemberRepository();
    }
}

이게 어떻게 가능한걸까? @Configuration을 달면 스프링 컨테이너에서 객체 위치추적이라도 해서 중복 생성하지 못하게 만들어주는 걸까?

 

---

# 스프링 Application Context의 동작방식

컨테이너를 구현할 때 설정객체가 생성하는 방식과 (=Object Factory)했던 방식과 스프링에서의 App..Context은 어떻게 다른지 알아보자.

• 클라이언트는 구체적인 팩토리 클래스(생성, 설정정보)를 알 수 없고, 알 필요도 없다.
• App..Context는 앱 전체에 종합적인 IoC 서비스를 제공해준다.
• App..Context는 등록된 서비스 객체(스프링빈)를 편하게 주입할 수 있도록 다양한 검색 방법을 제공한다.

기존에 우리가 만들었던 AppConfig(또는 UserDaoFactory)는 단순히 객체를 생성하고 필요한 관계를 맺어주는 제한적인 역할을 하는데 반해, 스프링의 App...Context는 전체 앱 자체에 IoC를 적용하여 서비스에 사용하는 모든 오브젝트에 대한 생성과 관계설정을 담당한다. 또한 DaoFactory와 달리 자바코드로 관계를 직접 맺는 것이 아니라 코드와 분리된 설정정보(@Bean)를 이용하여 개발자 코드와 별도로 존재하는 스프링의 오브젝트 팩토리에 그 작업을 위임하고, 결과를 가져다 사용한다.

 

스프링 컨테이너는 @Bean 이 붙은 메서드의 반환값을 스프링빈으로 만든다.

그리고 @Bean 메서드를 모아놓은 AppConfig 객체에 @Configuration을 사용하면 객체들의 의존관계를 주입하고, 각 객체를 싱글톤으로 유지하여 스프링 빈 중복 생성을 방지해준다. (설정을 통해 바꿀 수 있다. 기본값이 싱글톤)

repository() 를 여러번 호출해도, 한 객체만 참조하도록 싱글톤을 유지한다.

 

@ 스프링에서 싱글톤을 만드는 방법

스프링은 CGLIB라는 바이트코드 조작 라이브러리를 이용하여 싱글톤을 구현한다. 실제 컴파일한 바이트코드를 살펴보면 AppConfig.class 가 메모리에 로드되는게 아니라 AppConfig@CGLIB 라는 상속받은 클래스가 사용된다.

// CGLIB는 자바코드가 아닌 바이트코드를 직접 조작하기에 사용 방법이 어렵고 복잡하다.
// 이해를 돕기위해 자바코드로 비유하면 아래와 같이 동작한다.

class AppConfig@CGLIB123 extends AppConfig{
    @Bean
    public MemberRepository memberRepository() {
            if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) {
                return 스프링 컨테이너에서 찾아서 반환;

            } else { //스프링 컨테이너에 없으면
                기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
                return 반환
            }
    }
    ... 생략 ...
}

 

---

# 스프링 IoC 용어정리

헷갈리지 않도록 스프링에서 제공하는 IoC 컨테이너(DI 컨테이너)와 관련된 용어들을 정리해보자.

 

• IoC와 DI
  - 제어의 역전(Inverse of Control)은 앱의 실행흐름(객체를 생성, 설정, 회수)을 서비스 객체(개발자)가 아닌 외부(스프링)에서 관리하는 것을 의미한다. 라이브러리와 프레임워크의 가장 큰 차이점이기도 하다.
  - 의존성 주입(Dependency Injection)은 IoC를 구현하는 방법 중 한가지로, 스프링 IoC에서 사용하는 방법이다. IoC를 구현하는 방법에는 DI 말고도 여러가지 방법이 있다는 거만 인지하고 있자.
  
  
• Bean (빈)
  - 빈 또는 빈 객체는 스프링이 컨테이너를 통해 IoC방식으로 관리하는 객체를 의미한다. 주의할 점은 스프링에서 사용하는 모든 객체가 빈인 것이 아니라, 스프링이 직접 생성과 제어를 담당하는 오브젝트만 빈이라고 한다.
  
  
• Bean Factory(빈 팩토리)
  - 앞에서 만들었던 AppConfig 객체를 Object-Container라고 부르는 것 처럼 스프링의 IoC를 당당하는 핵심 컨테이너를 의미한다. 보통은 빈 팩토리를 바로 사용하지 않고 이를 상송받은 App...Context 객체를 이용해서 사용한다.
  
  
• Application Context(앱 컨텍스트)
  - 빈 팩토리를 상속받아 확장한 IoC 컨테이너다. 빈 팩토리에서는 객체의 생성과 관리만을 담당했었다면, 앱 컨텍스트는 스프링이 제공하는 각종 부가기능들을 추가로 제공한다.
  
  
• Configuration Metadata(설정정보, 메타정보)
  - 앱 컨텍스트(빈 팩토리)를 설정하기 위한 메타정보를 의미한다. 정말 스프링에 필요한 설정 정보를 적는 경우도 있지만, 보통은 IoC 컨테이너에 의해 관리될 객체를 구성하기 위해 많이 사용한다.
  - 참고로 스프링은 다양한 방식으로 설정정보를 작성할 수 있다. 옛날에는 xml방식으로 많이 작성했었는데, 요즘은 설정파일을 분리하지 않고 자바코드에 바로 적을 수 있는 어노테이션방식(@Configuration)를 주로 사용한다.
  
  
• Container (DI 컨테이너)
  - IoC 방식으로 빈 객체를 관리한다는 의미에서 위의 [앱 컨텍스트, 빈 팩토리]를 IoC 컨테이너라고 부르기도 한다. 어플리케이션 컨텍스트라고 하는 것 보다 IoC 컨테이너라 부르는게 더 의미가 정확하게 전달되는 효과도 있다.
  - 다만 IoC라는 용어는 범용적인 단어이기에, 스프링에서는 IoC를 DI로 구현한다는 의미에서 DI 컨테이너라고도 부른다. 이 둘은 같은 단어이다. 정확히는 Dependency Injection을 통해 IoC를 구현한 컨테이너라고 이해하면 된다.
  
  
• Spring Core (스프링 프레임워크)
  스프링 프레임워크는 IoC 컨테이너(앱 컨텍스트)를 포함해서 스프링이 제공하는 모든 기능을 통틀어 말할 때 주로 사용한다. 보통 Spring Core라 함은 앱을 만드는데 사용하는 핵심기능들 (IoC컨테이너, AOP, 이벤트등)을 의미하지만 보통 '스프링'이라 하면 스프링 진형에서 제공하는 다른 기능들을 포함한 의미로 많이 사용한다.
  

  

  스프링은 2004년에 나왔지만, 스프링MVC가 대중화 된 것은 2010년 무렵이다.

  스프링 프레임워크에서는 필요에 따라 기술(도구)들을 골라서 사용할 수 있도록 제공해준다. 자주 사용하는 핵심기능들 이외에도 현업 서비스에 필요한 거의 모든 도구를 제공한다.

  

  스프링 Core 말고도 다양한 기능들이 있다.

  
  

  ---

#IoC의 의미

IoC는 소프트웨어에서 자주 발견할 수 있는 일반적ㅇ니 개념이다. 객체지향적 설계, 디자인 패턴, 그리고 컨테이너에서 동작하는 서버기술을 동작한다면 자연스럽게 IoC를 적용하거나 비슷한 원리를 사용하게 된다.

 

그래서 IoC라고 단순 칭하게되면 서블릿 컨테이너처럼 동작하는 서비스 컨테이너를 의미하는 건지, 템플릿 메서드 패턴을 이용한건지, 아니면 또 다른 IoC 기술인건지 의미가 명확하지 않기에 스프링에서는 DI 컨테이너라는 명확한 이름을 사용하는 것이다.

 

 

# 의존관계 검색과 주입

스프링에서 제공하는 IoC는 컨테이너가 설정정보를 참조하여 의존관계 주입(@Configuration, @Bean) 해주는 방법도 있지만, App..Context를 이용하여 직접 의존관계를 검색(DL, Dependency Lookup)해서 설정하는 방법도 제공해준다.

public UserDao(){
	AnnotationConfigApplicationContext context = 
      new AnnotationConfigApplicationContext(DaoFactory.class);
      
     // getBean으로 직접 원하는 객체를 검색해서 연결시킨다.
    this.connectionMaker = context.getBean("connectionMaker", ConnectionMaker.class);
}

이렇게 하면 설정 객체(AppConfig)를 스프링 빈으로 등록하지 않아도 된다는 장점이 있긴하나, 의존관계를 주입받는 쪽이 훨씬 단순하고 깔끔하다. 이러한 방법을 DL이라고 부른다는 것만 알고 일단은 넘어가도록 하자.

 

 

# 스프링의 유연함, 다양한 설정정보 작성방법

스프링은 어노테이션, XML을 포함한 다양한 방법으로 설정정보를 읽어들일 수 있다.

하지만 스프링 컨테이너에는 설정정보를 '읽는 인터페이스'만 존재할 뿐, 어떻게 읽는지는 적혀있지 않다. 

@어노테이션, 설정.xml, 그 외 필요하다면 확장할 수도 있다.

스프링에서 제공하는 설정정보 Reader 구현체, 또는 내가 직접만든 Reader를 이용해 BeanDefinition을 구현만 하면 사용할 수 있는 것이다. 스프링 자체의 코드를 볼 일은 없겠지만, 이처럼 스프링 자체도 객체지향을 활용해 유연하게 구성되어있다는 것만 알고 넘어가도록 하자.

참고로 BeanFactory와 ApplicationContext는 구현코드가 없는 인터페이스이다.