Controller , Service , Repository로 분리
클라이언트의 요청 -> 서비스(비즈니스 로직 담당)에서 처리된 결과를 클라이언트에게 반환
서비스에서 DB저장 및 조회가 필요 -> Repository에 요청한 값을 서비스에 반환
Repositoy는 Database를 관리하여 CRUD작업을 진행
1주차에서 만든 코드의 제어의 흐름은 Controller -> Service -> Repository로 진행이 되었다.
1. Controller에서 Service로
MemoController에서 MemoService를 사용해야하기 때문에 생성자에 JdbcTemplate을 넣어주고 있다.
2. Service에서 Repository로
MemoService에서 자신은 사용하지 않지만, MemoRepository를 사용하기 위해 MemoRepository의 생성자에 JdbcTemplate을 넣어주고 있다.
강한 결합을 할 경우 다음과 같은 문제가 발생한다.
강한 결합 상태의 메모장 프로젝트는 비효율적인 코드 구성이다.
Controller ⇒ Service ⇒ Repository 순으로 이어진다.
예시
MemoController 클래스 수정
MemoService 클래스 수정
이제는 더 이상 MemoController와 MemoService에서 사용하지도 않는 JdbcTemplate을 주입 받아와 MemoRepository애 주입해줄 필요가 없어졌다.
프로그램의 제어 흐름이 뒤바뀐 것을 의미한다.
강한 결합 상태의 메모장 프로젝트 => 비효율적인 코드 구성
제어의 흐름: Controller ⇒ Service ⇒ Repository 순
제어의 흐름 Repository ⇒ Service ⇒ Controller 로 역전함으로써 효율적인 코드로변경
Bean: Spring이 관리하는 객체
Spring IoC 컨테이너: Bean들을 모아둔 컨테이너
bean으로 등록하고자 하는 클래스 위에 @Component 어노테이션을 달아서 설정한다.
이때 Spring Bean에서는 클래스의 앞글자만 소문자로 변경하여 저장한다.
ex. public class Memoservice일 경우 → memoservice 객체로 저장한다.
이것이 가능한 이유는 SpringBootApplication에 @ComponentScand이라는 기능이 존재하기 때문.
스프링 DI(Dependency Injection)에서 사용되는 어노테이션
스프링에서 Bean 인스턴스가 생성된 이후 @Autowired를 설정한 메서드가 자동으로 호출되고, 인스턴스가 자동으로 주입된다. → 해당 변수 및 매서드에 스프링이 관리하는 Bean을 자동으로 매핑하는 개념
Bean으로 주입하려는 변수, Setter메서드, 생성자, 일반 메서드에 적용이 가능하며, @Autowired 어노테이션을 붙여야 한다.
이 중 생성자 주입을 가장 추천한다. 그 이유는 객체의 불변성을 지켜줄 수 있기 때문이다.
이때 Autowired가 생략이 가능한 경우도 있다.
생성자 선언이 1개일 때만 생략이 가능하다.
참고: https://melonicedlatte.com/2021/07/11/232800.html → Spring Bean 정리된 타인 블로그
클래스에 @Component로 Spring Ioc컨테이너로 관리가 되고 있을때만 변수, 매서드, 생성자 등에 @Autowired 어노테이션으로 주입할 수 있다.