당니의 개발자 스토리

BeanFactory와 ApplicationContext 이번 시간에는 BeanFactory와 ApplicationContext에 대해서 알아보겠습니다. 위의 계층구조가 보면, 최상위에 BeanFactory라는 인터페이스가 있습니다. 인터페이스끼리는 상속받는다고 표현하는데, 그래서 이 BeanFactory를 상속받은 ApplicationContext 인터페이스가 BeanFactory 밑에 있는 거에요. 따라서, ApplicationContext는 BeanFactory에다가 부가기능을 더한 거라고 이해할 수 있겠죠. 그리고 ApplicationContext 밑에는 우리가 사용했던 AnnotationConfigApplicationContext 같은 구현 객체(클래스)가 있습니다. 먼저 BeanFactory에..

스프링 빈 조회 - 상속 관계 스프링 빈 조회 상속관계인데요. 만약에 빈을 조회할 때 얘들이 의존관계가 아닌, 상속관계로 되어있어요. 예를 들어서, 제가 어떤 애를 부모 타입으로 조회했는데, 자식이 여러 개 있어요. 그럼 어떻게 될까요? 간단합니다. 스프링 빈을 조회할 때는 기본 대원칙이 부모 타입으로 조회를 하면, 부모의 자식 빈들은 다 끌려 나와요. 그래서 다 같이 조회가 돼요. 이게 나중에 뒤에 자동 의존관계 주입부터 시작해서 어떻게 되는지 고민하실 수도 있는데 고민 안 해도 돼요. 자식 타입은 그냥 다 끌려 나온다고 생각하시면 됩니다. 이게 이제 대원칙이에요. 이거 한 가지만 기억하시면 뒤에 거는 그냥 다 술술 풀리게 됩니다. 그래서 모든 Java 객체의 최고 부모인 Object type으로 조회..

스프링 빈 조회 - 동일한 타입이 둘 이상 스프링 빈으로 조회할 때 동일한 타입이 둘 이상이면 오류가 발생해요. 이걸 타입으로 조회할 때 같은 타입의 스프링 빈이 둘 이상이면 스프링이 '어? 뭘 선택해야 되지?' 곤란스러워하면서 오류가 발생하는데요. 이때는 빈 이름을 지정해주시면 됩니다. 그리고 참고로 ac.getBeansOfType()을 사용하면, 해당 타입의 모든 빈을 조회할 수 있어요. 한번 보여드릴게요. beanfind에 ApplicationContextSameBeanFindTest 라는 테스트를 만들겠습니다. cmd + e 해서 최근 테스트에서 위 코드를 복사 붙여넣기 하고, 타입으로 조회 시 같은 타입이 둘 이상 있으면, 중복 오류가 발생하는 경우의 test를 만들 겁니다. 이렇게 하면 될까요..

스프링 빈 조회 - 기본 이번 시간에는 스프링 빈을 조회하는 가장 기본적인 조회 방법부터 하나씩 알아보겠습니다. 빈을 조회하는 가장 간단한 방법은 ac.getBean(빈이름, 타입) 이라는 메서드를 쓰면 되구요. 파라미터로 빈 이름과 타입을 주면 됩니다. 또는 ac.getBean(타입)처럼 빈 이름을 생략하고 타입만 줘도 됩니다. 그런데 조회하려고 하는 스프링 빈이 없을 수도 있죠. 그러면 NoSuchBeanDefinitionException 이라는 예외가 나요. 바로 코드로 직접 보겠습니다. beanfind에다가 ApplicationContextBasicFindTest 라고 할게요. public은 지워도 됩니다. cmd + e 해서, ApplicationContextInfoTest를 보고 스프링 컨테이..

컨테이너에 등록된 모든 빈 조회 이번 시간에는 이 컨테이너에 등록한 빈들이 제대로 등록이 됐는지 확인을 해볼게요. 분명히 뭔가 등록을 한 것 같긴 한데.. @Bean 하면 자동으로 등록이 되어버리니까 확인을 하고 싶은거죠. 테스트 코드로 한번 짜볼게요. test 폴더에 hello.core에다가 beanfind 라는 패키지를 만들겠습니다. 빈을 찾겠다는 의미입니다. 그리고나서, 스프링 컨테이너에 있는 빈을 조회하는 ApplicationContextInfoTest 라는 클래스를 만들겠습니다. 그리고 ac라는 스프링 컨테이너를 만들어주고요. 이 스프링 컨테이너는 AppConfig 설정 정보를 보고 빈을 등록하겠죠. 그리고 나서, 이렇게 하고 모든 빈을 출력해보겠습니다. JUnit 5부터는 public으로 설정..

4. 스프링 컨테이너와 스프링 빈 이번 시간에는 스프링 컨테이너와 스프링 빈에 대해서 알아보겠습니다. 기존에는 스프링의 핵심 원리들, 객체 지향에 대한 것들에 대해서 설명을 했구요. 그렇게 해서 왜 스프링이 만들어졌는지 설명했다면, 이제부터는 진짜 스프링 그 자체에 대해서 쭉 설명을 해드릴 거에요. 자 먼저 가장 중요한 스프링 컨테이너와 스프링 빈에 대해서 쭉 설명을 해드릴게요. 첫 번째로 스프링 컨테이너가 어떤 식으로 생성이 되는지 먼저 설명을 해드리겠습니다. 먼저 스프링 컨테이너가 생성되는 과정을 한번 알아볼게요. 스프링 컨테이너는 AnnotationConfigApplicationContext를 객체로 생성하면서, AppConfig.class를 파라미터로 넘깁니다. 그렇게 하면 반환 값으로 Appli..

스프링으로 전환하기 드디어 이번 시간부터 스프링을 써볼 거에요. 지금까지는 스프링 1도 없이 개발을 한 거죠. 프로젝트 세팅할 때야 그냥 스프링 하면 편하니까 했는데, 정말 순수한 Java 코드로 지금까지 짰는데 이제는 이거를 스프링으로 바꿔보겠습니다. 지금까지는 순수한 Java 코드만으로 Dependency Injection(의존관계 주입)을 적용했죠. 이제 이걸 스프링을 써서 해보겠습니다. 먼저, AppConfig를 스프링 기반으로 변경해보겠습니다. AppConfig에다가 구성정보, 설정정보 라는 의미의 @Configuration 애노테이션을 적습니다. 그 다음에 스프링 빈이라는 의미의 @Bean을 객체를 생성하는 곳마다 붙여주는 거에요. @Configuration이 붙어있으면, 이 AppConfig..

IoC, DI, 그리고 컨테이너이번 시간에는 IoC, DI, 그리고 컨테이너 라는 용어에 대해서 알아 보겠습니다.먼저 스프링을 공부하면, 제어의 역전, IoC, 이런 단어를 많이 들어 보셨을텐데요.이건 스프링에만 국한된 단어는 아닙니다. 보통은 개발자가 원하는 대로 객체를 생성하고 호출하고, 또 그 안에서 그 다음 걸 생성하고 호출하고, 이런 식으..