본 캠프_58일차

Spring 애플리케이션에서 이 구조는 계층 간 책임 분리와 유지보수성 향상을 위해 핵심적인 역할을 한다.

---

✅ 1. Controller – Service – Repository 구조란?

이 구조는 3계층 아키텍처(Three-tier architecture)의 한 형태이다:

계층	책임 역할	예시
Controller	외부 요청 처리, 응답 반환 (API 진입점)	HTTP 요청 매핑
Service	비즈니스 로직 수행	사용자 등록, 주문 처리 등
Repository	DB 접근, 데이터 조회/저장	JPA, JDBC 등을 이용한 DB 연동

---

✅ 2. DI가 필요한 이유 (이론적 배경)

🔸 문제: 객체 간 직접 생성 (new)

• 각 계층이 하위 객체를 new로 직접 생성하면 강한 결합이 생김
• 테스트, 확장, 유지보수가 어려워짐

public class UserService {
    private UserRepository repo = new UserRepository(); // ❌ 강한 결합
}

🔸 해결: DI(Dependency Injection)

• 객체 생성을 **프레임워크(Spring)**에게 맡기고
• 필요한 객체는 외부에서 주입 받음

이렇게 하면 계층 간 결합도는 낮추고 유연성은 높임

---

✅ 3. Spring에서 DI는 어떻게 동작하나?

핵심 개념 1: Bean

• Spring이 관리하는 객체 (DI 대상)
• @Component, @Service, @Repository, @Controller 등을 붙이면 Bean으로 등록됨

핵심 개념 2: IoC 컨테이너

• Spring의 핵심: 객체를 생성하고 관리하고 주입하는 의존성 주입 컨테이너
• 개발자는 객체를 new로 만들지 않고, Spring이 필요한 객체를 자동으로 넣어줌

---

✅ 4. Controller-Service-Repository 간 DI 흐름

이론적 흐름:

HTTP 요청
   ↓
[Controller]
   ↓ (Service 주입)
[Service]
   ↓ (Repository 주입)
[Repository]
   ↓
DB 접근

Spring은 다음을 자동으로 수행:

1. 애플리케이션 시작 시 @ComponentScan으로 Bean 탐색
2. UserController가 UserService를 생성자 파라미터로 가지면
   Spring이 자동으로 UserService 객체를 찾아 주입
3. UserService도 UserRepository가 필요하므로 마찬가지로 주입

---

✅ 5. DI 방식은 생성자 주입이 권장됨

방식	설명	권장 여부
생성자 주입	생성자로 의존 객체를 받음	✅ 가장 권장
필드 주입	@Autowired 필드에 직접 주입	❌ 지양
세터 주입	@Autowired setter 메서드 이용	🔸 조건부 사용 (선택적 의존성에 적합)

---

✅ 결론 요약

• Controller–Service–Repository 구조는 책임 분리와 확장성을 위한 기본 구조
• 각 계층은 하위 계층에 의존하지만, 직접 생성하지 않고 Spring이 주입
• Spring이 이걸 가능하게 해주는 것이 DI + IoC 컨테이너
• 이 과정을 통해 낮은 결합도, 높은 테스트성, 유지보수성을 확보할 수 있음