IOC 에 대해서

개념

IoC (Inversion of Control)

프로그램 제어 흐름 구조가 뒤바뀌는 것

1. 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지않습니다.
2. 스스로 생성하지도 않습니다
-> 모든 제어 권한을 자신이 아닌 다른 상대에게 넘겨주기 때문

예를 들어 서블릿으로 비유하자면 우리는 서블릿을 서버에 직접 배포할 순 있지만 서블릿을 직접 제어할 수 있는 방법은 없습니다 왜냐면 모든 제어권을 컨테이너가 가지고있기 때문입니다.

OrderFactory 는 OrderRepository 메소드를 호출하면 OrderServiceNOSQL 생성 후 코드를 이용한 동작을 OrderRepository 에 넘겨줍니다. DaoFactory

public class OrderFactory {
    public OrderRepository orderRepository() {
        return new OrderRepository(new OrderServiceNOSQL());
    }        
}

ApplicationEntry 는 어떻게 초기화하는지 신경쓰지않고 런타임만 신경쓰면 됩니다. 런타임 시점인 ApplicationEntry

public class ApplicationEntry {
    public static void main(String[] args) {
        OrderRepository  orderRepository = new OrderFactory().orderRepository();
    }
}

Spring IoC

스프링 IoC 가 있습니다 위에 제가 만들었던 OrderFactory의 역할을 좀 더 일반화해서 만든 것이

1. Bean Factory
2. Application Context

일단 Bean 은 뭐냐???

-> 스프링이 제어권을 가지고 직접 만들고 관계 부여하는 오브젝트(객체)를 Bean 이라고합니다.

스프링은 제어권을 가지고 빈을 빈 팩토리에서 생성과 관계설정을 합니다

하지만 좀 더 기능이 확대되서 나온 놈이 하나 더 있습니다! 바로 Application Context 입니다.

OrderFactory 같은 경우 특정 클래스의 생성과 관계설정만 했다면 Application Context 는 이런 직접적인 정보는 없지만 설정정보를 활용하는 범용적인 IoC엔진이 됩니다.

DaoFactory

@Configuration //Application Context 가 사용할 설정 정보라는 표시!
public class OrderFactory {
    @Bean  //Bean 으로 생성 담당 IoC용 메소드 표시!
    public OrderRepository orderRepository() {
        return new OrderRepository(new OrderServiceNOSQL());
    }        
}

Application Context 를 적용한 ApplicationEntry

public class ApplicationEntry {
    public static void main(String[] args) {
        ApplicationContext context = 
                new AnnotationConfigApplicationContext(OrderFactory.class);
            OrderRepository repository = context.getBean("orderRepository", OrderRepository.class);
    }
}

getBean() 을 하면 빈 으로 등록된 애들 중 orderRepository 를 가져오겠다는 뜻입니다 빈으로 가져온다는 건 OrderFactory 의 orderRepository() 메소드를 호출해서 결과를 가져오겠다는 뜻이 되는 것입니다!