#dependency injection

의존성 주입 Dependency Injection : 사용하는 객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법 의존성 주입 기법 생성자 주입 Setter 주입 메서드 주입 SERVICE LOCATOR 패턴 서비스를 사용하는 코드로부터 서비스가 누구인지 (서비스를 구현한 구체 클래스의 타입이 무엇인지), 어디에 있는지(클래스 인스턴스를 어떻게 얻을지)를 몰라도 되게 해준다. 사용처에서 특정 인스터스에 의존하기 원한다면 아래와 같이 사용해야 한다. Movie 생성자 만으로 의존성이 해결되지

지난 글에서 DAO 오브젝트 팩토리를 스프링의 Application Context로 변환하는 과정까지 했다. 이 과정에서 @Configuration이라는 어노테이션으로 Application Context가 빈을 만들 수 있게 했다. 그런데 오브젝트 팩토리로 만든 DAO는 여러개 생성이 가능하고 그렇게 되면 동일하지 않게된다. Application Context로 만든 DAO는 동일하다. IoC컨테이너인 Application Context는 Singleton Registry다. 스프링은 빈을 생성할때 기본적으로 Singleton으로

서비스 객체가 있을때 비즈니스 로직을 처리하는 경우 저장소의 객체를 직접 들여다 볼 수 있다. 위와 같은 코드가 있을때 서비스 객체를 생성한다면 자연스럽게 저장소 객체도 생성된다. 이 경우를 두고 '서비스가 저장소에 의존된다'라고 말한다. 의존경우가 있을 경우엔 어떤 일이 생길까? 위와같이 모든 서비스 코드에서 의존관계가 종속된다면 의존에 관련된 코드를 수정 할 때 마다 서비스코드도 전부 수정해야한다. 생성자를 통해 객체를 받아서 처리하면 의존관계를 해결할 수 있다. 스프링의 DI는 여러가지 방법이 있는데 크게 3가지만 아래 정리해

본격적으로 스프링에서 사용되는 코드 패턴과 개념에 대해서 파고 들어간다. 제어의 역전 객체를 직접 생성하지 않고 외부에서 구현체를 넣어줌으로써 제어권을 거꾸로 가지고 가는 현상 IoC는 즉, 설계의 패턴이다. 실체에 의존할 것인가 추상화에 의존할 것인가 의존성 주입 외부에서 의존성을 받는 행동. 즉, 외부에서 new로 생성된 객체를 받는다. DI는 즉, 동작 그 자체다. 의존성을 어떻게 가질 것인가? 관계를 짧고 쉽게 정리하자면 → DI를 하면 IoC가 일어난다. 객체의 생성, 소멸, 작동의 주도권(즉, 제어권)이 객체 자신에게 있