web +a (58) 썸네일형 리스트형 자동주입 - 옵션 처리 @Autowired에서 주입가능한 스프링 빈이 없어도 동작해야 할 때가 있다. cf. required 옵션 디폴트가 true라서 주입대상이 없으면 오류가 발생한다. ↓ 자동 주입 대상을 설정해야 한다. 자동 주입 대상을 옵션으로 처리하는 방법을 알아보자 ↓ 예제) 스프링빈으로 관리되는 객체가 아닌 Member객체를 @Autowired 메서드의 매개변수로 넣은 상태다. 즉 @Autowired에서 주입가능한 스프링빈이 없는 상태이다. static class TestBean { //1. //호출 안됨 - 의존관계가 없을 경우 아예 호출안됨 @Autowired(required = false) public void setNoBean1(Member member) { System.out.println("setNoBe.. 컴포넌트 스캔 ∨ 등록해야할 스프링빈이 엄청 많아지면 @Bean으로 다 등록해주기가 까다로워짐 => 스프링이 컴포넌트 스캔 기능 제공 이전 : @Configuration에서 @Bean을 통한 수동 bean 등록 - 의존관계가 직접 명시되어있었다. 지금 하는 거 : @ComponentScan을 통한 자동 bean 등록 (즉, @Bean 사용X) - @Component가 붙은 클래스들을 스캔 -> 스프링빈으로 등록 - 각 빈에 대해 의존관계를 명시하지 않는다 => 그럼 어떻게 DI 주입? => @Autowired가 의존관계를 자동으로 주입해준다. ● 예시 더보기 ① 컴포넌트 스캔 기능을 이용하기 위해서 @ComponentScan을 붙인 설정정보(@Configuration) AutoAppConfig를 만들었다. cf. 저 .. 싱글톤 컨테이너 이번 챕터는 머릿속에 잘 정리했기 때문에 여긴 메모만 아무렇게나 했다. ∨ 웹애플리케이션은 고객 요청이 끊임없이 들어옴 : 그때마다 새로운 객체를 생성하는건 좋지 X : 트래픽↑면 메모리효율↓↓↓↓ ∴ 싱글톤 더보기 예제 public class SingletonService { // static 영역에 객체 instance를 하나 생성해서 올려둔다. private static final SingletonService instance = new SingletonService(); // 이 객체 인스턴스가 필요하면 오직 getInstance() 통해서만 조회 가능 // 매번 같은 인스턴스 반환 public static SingletonService getInstance() { return instance; .. 스프링 빈 조회 (getBean) - 상속관계인 경우 ∨ 부모타입으로 조회 => 자식빈들이 다 끌려나옴 cf. Object타입으로 조회하면 다 조회된다. . . 부모타입으로 조회하는 경우 발생할 수 있는 여러 케이스들을 만나보자. 각 케이스에 대한 테스트코드를 작성해보며 진행하자. ※ 참고 : test코드에서 print문 찍어서 눈으로 확인하는 건 실제로 별로 의미 없고 할 일도 없다. 지금은 그냥 학습용도로 찍어보는 것이다. 실무에서는 테스트 통과&실패 사실만 의미있음! . . ∨ TestConfig : 더보기 @Configuration static class TestConfig { @Bean public DiscountPolicy reteDiscountPolicy() { return new RateDiscountPolicy(); } @Bean publi.. (컨테이너에 등록된) 스프링 빈 조회해보기 Test코드를 작성하며 진행해보자. 스프링 빈 조회하기! ① 컨테이너에 등록된 모든 빈 조회하기 ∨ 스프링 자동완성 축약어 iter : 존재하는 리스트에 대하여 향상된 for문을 만들어준다. (그냥for문 : itar) ∨ .getBeanDefinitionNames() : 스프링 빈 객체 이름 가져와 리스트로 만들어줌 ∨ .getBean(빈 이름) : 이름을 통해 스프링빈 객체를 가져와줌. 타입지정안하면 Object로 받을 수 있나보다. ∨ .getBeanDefinition(빈 이름) : BeanDefinition객체를 반환한다. class ApplicationContextInfoTest { AnnotationConfigApplicationContext ac = new Annotatio.. 스프링 컨테이너 첫 이용 이전에는 AppConfig를 직접 가져와서 DI했지만 이번에는 스프링 기능을 활용할 것이다. 스프링 DI컨테이너가 관리할 수 있도록 AppConfig 파일에 어노테이션을 추가해주자. ∨ 설정파일이라는 뜻에서 AppConfig에다가 @Configuration을 붙인다. ∨ 여기서 @Bean 메서드가 호출되어 반환된 객체는 스프링 컨테이너에 등록된다. 그러한 객체를 스프링 빈이라고 한다. 스프링 빈 이름 : 메서드 이름 import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class AppConfig { @Bean publ.. IoC/DI컨테이너 참고 (이전 학습) : DIP, OCP 원칙이 깨지는 문제를 Spring으로 해결 AppConfig 리팩터링 (+ 역할 요약) IoC/DI 컨테이너 AppConfig에다가 의존관계 주입을 맡겨보았다. ∴ 좋은 객지설의 원칙 OCP, DIP를 준수하게끔 했고, 클라이언트 코드를 변경하지 않고 구현체를 변경할 수 있었다. 지금까지 공부한 것을 요약하자면 아래와 같다. "제어 흐름에 대한 권한을 가지는 것은 내부가 아닌 외부파일 AppConfig이다. 이러한 제어의 역전(Inversion of Control)은 곧 의존관계 주입(Dependency Injection)을 실현한다." * DI와 IoC는 객체간 상호결합을 낮춰서 더욱 유연하고 객체지향적인 개발을 가능케 한다. ↓↓↓ 즉, 우리가 구현한 AppCo.. AppConfig 리팩터링 (+ 역할 요약) 이전 학습 내용 : AppConfig를 따로 두어서 생성&주입의 책임을 서비스 클래스의 외부(AppConfig)로 빼주었다. 의존관계 주입(DI)를 구현한 것이다. 그런데 단순히 구현해본 AppConfig는 리팩터링이 필요하다. 그 내용을 보쟛 (단축키 : Ctrl + Alt + M) ∨ 이전 - 중복 제거가 필요 : 매개변수를 보자. new MemoryMemberRepository()가 중복으로 있다. : 중복 제거가 필요하다 => 다른 구현체로 변경할 경우 힘들어짐 : 그 new하는 책임을 메서드 하나로 따로 빼주자. - 애플리케이션의 구조가 보이지 않음 : 역할&구현이 분리되지 않았다. : 예를들면 memberService 역할 속에 new MemoryMemberRepository()라는 구현체 생.. 이전 1 ··· 3 4 5 6 7 8 다음
