🌱 Spring
☘️ 의존관계 자동 주입
🟦 의존관계 주입 방법
🔹 생성자 주입
🔹 수정자(setter) 주입
🔹 필드 주입
🔹 일반 메서드 주입
🔷 생성자 주입
생성자를 통해서 의존관계 주입
생성자 호출 시점에 1번만 호출되는 것 보장
주로 불변, 필수 의존관계에 사용
( (스프링 빈)생성자가 1개만 있을 때 -> @Autowired 생략해도 의존 관계 자동 주입 )
@Component
public class VehicleServiceImpl implements VehicleService {
private final VehicleRepository vehicleRepository;
private final ParkingRule parkingRule;
@Autowired // 생성자 1개인 경우 @Autowired 생략 가능
public OrderServiceImpl(VehicleRepository vehicleRepository, ParkingRule parkingRule) {
this.vehicleRepository = vehicleRepository;
this.parkingRule = parkingRule;
}
}VehicleServiceImpl을 스프링 빈에 등록하면서 의존 관계 주입
⭐ DI 프레임워크 대부분은 생성자 주입을 권장
➡️ 불변하게 설계 가능 & 누락 방지 & final 키워드 사용 가능
프레임워크에 의존 X, 순수한 자바 언어의 특징을 살리는 방법
기본으로 생성자 주입을 사용, 필수 값이 아닌 경우에만 수정자 주입 사용
✔️ 불변
▪️ 되도록 의존관계는 애플리케이션 종료 전까지 변하면 안됨
▪️ setter 주입을 사용하려면 setter메서드를 public으로 열어두어야 함
-> 타인의 수정이 가능, 변경하면 안되는 메서드를 열어두는 것은 좋지 못함
▪️ 생성자 주입은 객체를 생성할 때 1번만 호출됨
-> 불변하게 설계 가능
✔️ 누락
▪️ 생성자 주입 사용시 주입 데이터 누락했을 경우 컴파일 오류 발생
✔️ final 키워드
▪️ 생성자 주입 사용하면 final 키워드 사용 가능
-> 생성자에 값이 설정되지 않는 오류를 컴파일 시점에 막을 수 있음
🔷 수정자 주입(setter 주입)
필드의 값 변경하는 수정자 메서드를 통해 의존관계 주입
선택, 변경 가능성이 있는 의존관계에 사용
@Component
public class VehicleServiceImpl implements VehicleService {
private final VehicleRepository vehicleRepository;
private final ParkingRule parkingRule;
@Autowired
public void setVehicleRepository(VehicleRepository vehicleRepository) {
this.vehicleRepository = vehicleRepository;
}
@Autowired(required = false) // 주입할 대상이 없어도 동작하도록
public void setParkingRule(ParkingRule parkingRule) {
this.parkingRule = parkingRule;
}
}VehicleServiceImpl을 스프링 빈에 등록한 후에 의존 관계 주입
🔷 필드 주입
필드에 바로 주입하는 방법
코드 간결 / but 외부에서 변경 불가능 -> 테스트하기 힘듦 + DI 프레임워크가 필수
➡️ 사용 ❌
@Component
public class OrderServiceImpl implements OrderService {
@Autowired
private VehicleRepository vehicleRepository;
@Autowired
private ParkingRule parkingRule;
}🔷 일반 메서드 주입
스프링 빈으로 등록된 클래스의 일반 메서드를 통해 주입
한번에 여러 필드 주입 가능 // 일반적으로는 잘 사용하지 않음
@Component
public class VehicleServiceImpl implements VehicleService {
private VehicleRepository vehicleRepository;
private ParkingRule parkingRule;
@Autowired
public void init (VehicleRepository vehicleRepository, ParkingRule parkingRule) {
this.vehicleRepository = vehicleRepository;
this.parkingRule = parkingRule;
}
}🟦 자동 주입 대상 옵션 처리
🔹 @Autowired(required=false) : 수정자 메서드 호출 안함
🔹 org.springframework.lang.@Nullable : 자동 주입할 대상 없으면 null입력
@Autowired
public void setVehicle(@Nullable Car car) {
}
// setVehicle = null🔹 Optional<> : 자동 주입할 대상 없으면 Optional.empty 입력
@Autowired
public void setVehicle(Optional<Car> car) {
}
//setVehicle = Optional.empty🟦 롬복 라이브러리를 통한 코드 최적화
플러그인에서 롬복 설치
file-settings-Annotation Processors에서 'Enable annotation processing' 체크
🔹 생성자가 1개만 있으면 @Autiwired 생략
🔹 @getter, @setter 어노테이션 ➡️ getter, setter 코드 생략
🔹 @RequiredArgsConstructor 어노테이션 ➡️ final 붙은 필드를 모아서 생성자 자동으로 생성
🟦 조회 빈이 2개 이상일 때의 해결 방안
스프링 빈은 Type으로 조회
➡️ OrderService의 하위 타입인 TabletOrderService와 QROrderService를 모두 스프링 빈으로 선언한다면 'NoUniqueBeanDefinitionException' 오류 발생
🔷 @Autowired 필드 명 매칭
동작 순서
1. 타입 매칭 시도
2. (1 실패) 타입 매칭의 결과가 2개 이상이면 필드명, 파라미터 명으로 빈 이름 매칭
@Autowired
private OrderService orderService
⬇️ 수정
@Autowired
private OrderService tabletOrderService🔷 빈 등록시 @Qualifier 사용
@Qualifier는 추가 구분자를 붙여주는 방법
동작 순서
1. @Qualifier끼리 매칭
2. (1 실패) 빈 이름 매칭
3. (2 실패) NoSuchBeanDefinitionException 발생
주입 받을 때, 모든 코드에 @Qulifier 붙여주어야 하는 단점
@Component
@Qualifier("mainOrderService")
public class TabletOrderService implements OrderService{}생성자 자동 주입
public OrderServiceImpl(MemberRepository memberRepository, @Qualifier("mainOrderService") OrderService
orderService) {
this.orderService = orderService;
}
수정자 자동 주입
@Autowired
public OrderService setOrderService(@Qualifier("mainOrderService") OrderService orderService) {
this.orderService = orderService;
}
🔷 @Primary 사용
우선순위를 정하는 방법, @Autowired로 여러 빈이 매칭되면 @Primary가 우선권을 가짐
@Component
@Primary
public class TabletOrderService implements OrderService {}
@Component
public class QROrderService implements OrderService {}우선순위는 자동보다 수동이 높음 -> @Qualifier가 @Primary보다 우선순위 높음
🟦 조회한 빈이 모두 필요할 때 -> List, Map 사용
예시.
static class OrderService {
private final Map<String, OrderService> orderMap;
private final List<OrderService> orders;
public OrderService(Map<String, OrderService> orderMap, List<OrderService> orders) {
this.orderMap = orderMap;
this.orders = orders;
}
public int order(Menu menu, int price, String orderCode) {
OrderService orderService = orderMap.get(orderCode);
return orderService.order(menu, price);
}
}🔹 로직
-
OrderService는 Map으로 모든 'OrderService'를 주입 받음
-
order() 메서드는 orderCode로 들어오는 문자열에 해당하는 스프링 빈을 map에서 찾아 실행
🔹 주입
-
Map<String,OrderService>
: map의 키에 스프링 빈의 이름을 넣고, 그 값을 이용해 OrderService 타입으로 조회한 모든 스프링 빈을 저장 -
List< OrderService >
: OrderService 타입으로 조회한 모든 스프링 빈을 저장, 조회된 빈이 없으면 빈 컬렉션 or Map을 주입
✅ 자동, 수동의 올바른 실무 운영 기준
▪️ 편리한 자동 기능을 기본으로 사용
자동 빈 등록을 사용해도 OCP, DIP 지킬 수 있음
▪️ 직접 등록하는 기술 지원 객체는 수동 등록
수동 빈 등록을 사용해서 명확하게 드러내는 것이 좋음
업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 레포지토리 등
기술 지원 빈 : 기술적인 문제나 AOP를 처리할 때 주로 사용, DB 연결이나 공통 로그 처리와 같은 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들
-> 업무 로직에 비해 수가 매우 적고, 적용이 잘 되고 있는지 파악하기 어려운 경우 多
-> 수동 빈으로 등록해서 설정 정보에 바로 나타나게 하는 것이 유지보수에 좋음
▪️ 비즈니스 로직 중에서 다형성 적극 활용할 때에는 수동 등록
코드만 보고 쉽게 파악이 안될 수 있음
-> 특정 패키지에 같이 묶어두고 자동 등록 사용 (특정 인터페이스의 구현 빈들만 따로 모아 특정 패키지에 모아둠)
-> OR 수동 빈으로 등록하여 한눈에 확인 파악하도록인프런 스프링 핵심 원리 - 기본편 (김영한) 참조
