[SPRING] Bean🫛, IoC, DI, @ComponentScan

🗄️ 스프링 컨테이너 & 빈

스프링 컨테이너

: 객체(Bean)를 생성 및 관리하고 의존성을 주입하는 역할
여기서 이 빈을 만드는 것의 담당자는 바로 스프링 컨테이너임ㅋ

🫛 빈 Bean

: Spring 컨테이너가 관리하는 객체
→ 원래는 그냥 자바 객체가 스프링을 만나서 스프링이 이 객체를 관리하게 되면서 그 순간부터 객체가 아니라 빈이 되는 것!
(new 키워드를 쓰지 않고도 사용할 수 있다)

< Spring Bean의 특징 >
1. Spring 컨테이너에 의해 생성되고 관리된다.
2. 기본적으로 Singleton으로 설정된다.
3. 의존성 주입(DI)을 통해 다른 객체들과 의존 관계를 맺을 수 있다.
4. 생성, 초기화, 사용, 소멸의 생명주기를 가진다.

Bean은 항상 싱글톤

수동 빈 등록이 자동 빈 등록을 오버라이딩 해서 우선권
-> 좀 더 자세히 작성된 빈이 우선으로 실행된다고 생각하면됨여

빈을 쓰면 결합도를 낮추고 응집도를 높여서 독립성을 높일 수 있삼
singleton패턴을 가지는데 이거 덕분에 여기저기서 막 하나의 객체를 공유해가지고 막 쓸수잇음

---

💉 의존성 주입(DI) & 제어의 역전(IoC)

의존성 주입(DI)과 제어의 역전(IoC)을 통해 다른 객체들과 의존 관계를 맺을 수 있다

1. IOC(제어의 역전, Inversion Of Control)

: 객체의 생성과 관리 권한을 개발자가 아닌 Spring 컨테이너가 담당하는 것
즉, 스프링이 객체를 대신 관리하게 하는 것

2. 의존성 주입(DI)

: Spring이 객체 간의 의존성을 자동으로 주입해주는 것
스프링이 알맞은 객체를 알아서 가져다 씀(해당 객체를 직접 생성(new)하지 않고 Spring이 주입)
→ 객체를 직접 만들 필요 없이, 필요한 곳에서 "이거 주세요!" 하면 됨!
→ 스프링이 관리하는 객체를 필요한 곳에 자동으로 넣어주는 것" (IoC의 한 방식)

개발자가 어 무슨 객체 필요하다~ 하면 알아서 그거에 맞는 객체 가져와가지고 맞는 객체를 넣어줌

💡 장점

• 유지보수가 쉬움
• 결합도를 낮추어 독립성을 높여줌

IoC는 더 큰 개념
DI는 IoC를 구현하는 방법 중 하나

💭 비유하자면...
IoC = "회사가 직원(객체) 관리를 직접 안 하고, HR(스프링)이 관리하게 맡기는 것"
DI = "HR(스프링)이 각 부서에 필요한 직원(객체)을 자동으로 배치해 주는 것"

✅ IoC → 개발자가 직접 객체를 만들지 않고, 스프링이 알아서 관리!
✅ DI → 개발자가 직접 new 안 해도, 필요한 객체를 스프링이 자동으로 주입!

---

🖨️ @ComponentScan

: Spring이 특정 패키지 내에서 Annotation(@Component, @Service, @Repository 등)이 붙은 클래스를 자동으로 검색하고, 이를 Bean으로 등록하는 기능

이전 투두 프로젝트를 만들때 클래스별로 @Repository @Conroller @Servie 등의 어노테이션을 붙여줬었다.
이 어노테이션을 통해 Spring이 각 클래스를 각각에 맞는 빈으로 자동 등록했었다

👉 ComponentScan 덕분에 네가 직접 Bean 등록을 하지 않아도, Spring이 어노테이션이 붙은 클래스들을 찾아서 자동으로 빈으로 관리!

그러니까 @Service 같은 걸 달아두기만 하면, 스프링 "아 이거 Bean으로 등록하라는거군 ㅋ" 하고 알아서 처리하는거~~~ 짱편하죠?

📁 basePackages

: 특정 패키지를 스캔할 때 사용, 배열로 여러개를 선언할 수 있다.

여러개의 패키지가 존재할때, 스프링이 어떤 패키지에서 어떤 어노테이션을 읽어야할지 혼란스럽잖아? 그때 basePackges를 사용해서 어떤 패키지에 있는 것들을 사용할건지 지정해줄 수 있다~~
- 예시: @ComponentScan(basePackages = {"com.example", "com.another"})

@ComponentScan 작동 순서

1. Spring Application이 실행되면 @ComponentScan이 지정된 패키지를 탐색
2. 해당 패키지에서 Annotation이 붙은 클래스를 찾기
3. 찾은 클래스를 Spring 컨테이너에 빈으로 등록.
4. 등록된 빈은 의존성 주입(DI)과 같은 방식으로 다른 빈과 연결

🎯 예시로 정리

🛒 ComponentScan = "창고에서 재료(빈)를 미리 찾아 준비하는 관리자"
👨‍🍳 DI = "쉐프가 필요한 재료를 요청하면 자동으로 제공"

→ 개발자는 직접 객체를 만들 필요 없이, 필요한 곳에서 요청만 하면 끝!! 🚀🔥

---

🎯 의존성 주입(DI) 방식 - 생성자 주입

⭐️ @Autowired : 의존성을 자동으로 주입할 때 사용하는 Annotation

가장 권장되는 방식이다

1. 생성자 주입

생성자로 객체를 받아서 주입하는 방식
가장 안정적이고, 불변성을 보장할 수 있어서 추천된다

@Service
public class OrderService {
    private final PaymentService paymentService;

    @Autowired // 🔥 생성자 주입
    public OrderService(PaymentService paymentService) { 
        this.paymentService = paymentService;
    }
}

필드에 final 은 생성자 주입 방식만 사용할 수 있다.

2. @RequiredArgsConstructor

:final 필드를 모아서 생성자를 자동으로 만들어 주는 역할
Annotation Processor 가 동작 → 컴파일 시점에 자동으로 생성자 코드 생성

@Component
@RequiredArgsConstructor //⭐️ 생성자 자동 주입
public class MyApp {
		
    private final MyService myService;

    public void run() {
        myService.doSomething();
    }
    
}

이떄, 필드에 final 키워드는 필수!
→ 무조건 값이 있도록 만들어준다

---

⚠️ Spring Validation & BindingResult

1. Validation

Spring에서 Validation은 클라이언트 요청 데이터가 유효한지 확인하는 과정!
→ 잘못된 데이터로 인해 발생할 수 있는 오류를 방지하고, 사용자 경험을 향상

미리 정해놓은 사항에 부합하는지 검증하는 것인데,
예를 들어 식당 메뉴판에 없는 메뉴를 주문할 수 없는 것처럼, 특정 데이터 형식과 값의 유효성을 검사하는것!

❓ 왜 해야할까?

• 잘못된 입력값으로 인해 서버 오류가 발생하면 사용자 경험이 나빠짐
• 오류 발생 시 작성 중이던 데이터가 초기화되면 불편함이 큼
• 적절한 검증을 통해 오류를 방지하고, 사용자에게 명확한 피드백을 제공해야 함

프론트엔드 / 서버 / 데이터베이스 검증 3가지가 있는데 이 중에서도
서버 검증이 필수이다
→ API에서 데이터 유효성 검사 수행
→ 검증 실패 시 적절한 응답을 반환해야 함

2. BindingResult

: Validation 오류를 저장하는 객체

@ModelAttribute 로 전달된 데이터에서 검증 오류가 발생하면 BindingResult 가 이를 보관!

👎 만약 BindingResult가 없으면?
요청 데이터 바인딩 실패 시 400 Bad Request 발생
컨트롤러가 호출되지 않고, 예외가 발생하여 오류 페이지로 이동

👍 BindingResult가 있으면!!!!
@ModelAttribute 바인딩 오류 발생 시, BindingResult가 오류 정보 저장
컨트롤러가 정상적으로 호출, 검증 오류가 발생한 필드를 제외한 나머지 값이 바인딩

🏁 BindingResult는 검증할 객체 뒤에 위치해야만 함

➡️ 이러한 검증을 통해 사용자 경험 향상 및 오류 방지 가능