두두의 IT/Spring (26) 썸네일형 리스트형 조회 빈이 2개 이상일 때 조회 대상 빈이 2개 이상일 때 해결 방법 1. @Autowired 필드명 매칭 먼저 타입 매칭을 시도하고 그 결과에 여러 빈이 있을 때 추가로 동작함 타입 매칭의 결과가 2개 이상일 때 필드명으로 빈 이름 매칭 2. @Qualifier -> @Qualifier끼리 매칭 -> 빈 이름 매칭 추가 구분자를 붙여주는 방법 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아니다 생성자/수정자에 @Qualifier 넣어주기 Qualifier는 Qualifier를 찾는 용도로만 사용하는게 명확하고 좋다. 3. @Primary 사용 @Autowired 시에 여러 번 매칭되면 @Primary가 우선권을 갖는다. 코드에서 자주 사용하는 메인 데이터베이스의 커넥션을 획득하는 스프링 빈이 있고, 코드에서 .. lombok 설정 1. build.gradle dependencies { //lombok 라이브러리 추가 시작 compileOnly 'org.projectlombok:lombok' annotationProcessor 'org.projectlombok:lombok' testCompileOnly 'org.projectlombok:lombok' testAnnotationProcessor 'org.projectlombok:lombok' } 2. IntelliJ 메뉴 > Preferences > Plugins > lombok 설치 3. IntelliJ 메뉴 > Preferences > Build, Execution, Deployment > Compiler > Annotation Processors > Enable annota.. 의존관계 자동 주입 의존관계 주입 방법 생성자 주입 생성자 호출 시점에 딱 1번만 호출되는 것이 보장됨 "불변, 필수" 의존관계에 사용 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다. (스프링 빈에만 해당함) 자주 사용 수정자 주입(setter) setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계 주입 "선택, 변경" 가능성이 있는 의존관계에 사용 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법 필드 주입 코드가 간결해서 많은 개발자들을 유혹하지만 외부에서 변경이 불가능해서 테스트하기 힘들다는 치명적 단점이 있음 DI 프레임워크가 없으면 아무것도 할 수 없다. 사용하지 말자 (테스트코드, @Configuration 가능) 일반 메서드 주입 한번에 여러 필드를 주입.. 컴포넌트 스캔 스프링 빈 등록 방법 1. XML 2. @Bean 3. @ComponentScan, @Component, @Autowired(생성자에서 여러 의존관계도 한 번에 주입 가능) 컴포넌트 스캔은 @Component 뿐만 아니라 다음 내용도 추가로 포함됨 @Component : 컴포넌트 스캔에서 사용 @Controller : 스프링 MVC 컨트롤러에서 사용. 스프링 MVC 컨트롤러로 인식 @Service : 스프링 비즈니스 로직에서 사용 @Repository : 스프링 데이터 접근 계층에서 사용. 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해준다. @Configuration : 스프링 설정 정보에서 사용. 스프링 설정 정보로 인식하고 스프링 빈이 싱글톤을 유지하도록 추가 처리.. 싱글톤 웹 애플리케이션과 싱글톤 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 개발할 수 있다. 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체를 새로 생성한다 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다! -> 메모리 낭비가 심하다 해결방안은 해당 객체가 딱 1개만 생성되고 공유하도록 설계하면 된다 -> 싱글톤 패턴 싱글톤 패턴 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴 그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다 pr.. BeanDefinition AnnotationConfigApplicationContext는 AnnotatedBeanDefinitionReader를 사용해서 AppConfig.class를 읽고 BeanDifinition을 생성한다 GenericXmlApplicationContext는 XmlBeanDefinitionReader를 사용해서 appConfig.xml 설정 정보를 읽고 BeanDefinition을 생성한다 새로운 형식의 설정 정보가 추가되면, XxxBeanDefinitionReader를 만들어서 BeanDefinition을 생성하면 된다. BeanDefinition 정보 BeanClassName : 생성할 빈의 클래스 명(자바 설정처럼 팩토리 역할의 빈을 사용하면 없음) factoryBeanName : 팩토리 역할의 빈을 .. BeanFactory와 ApplicationContext BeanFactory 스프링 컨테이너의 최상위 인터페이스 스프링 빈을 관리하고 조회하는 역할을 담당 getBean()을 제공 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능 ApplicationContext BeanFactory 기능을 모두 상속받아서 제공함 빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데, 그러면 둘의 차이가 뭘까? 빈을 관리하고 조회하는 기능은 물론이고, 수 많은 부가기능 제공 메시지 소스를 활용한 국제화 기능 : 한국-한국어, 영어권-영어 환경변수 : 로컬, 개발, 운영 등을 구분해서 처리 애플리케이션 이벤트 : 이벤트를 발행하고 구독하는 모델을 편리하게 지원 편리한 리소스 조회 : 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조.. 스프링 컨테이너 'ApplicationContext'를 스프링 컨테이너라 한다 기존에는 개발자가 'AppConfig'를 사용하여 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용한다 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정(구성) 정보롤 사용한다. 여기서 @Bean이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다 스프링 빈은 @Bean이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다(memberService, orderService) 이전에는 개발자가 필요한 객체를 AppConfig를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너를 통해서 필요한 스프링 빈(객체.. 이전 1 2 3 4 다음