Controller, Service, Repository 스프링 3계층 클래스를
1️⃣ 프로젝트 전체를 기반으로, BaeminController / BaeminService / BaeminRepository 이렇게 각 계층만 나누는 게 좋을까?
2️⃣ 도메인 별로, FoodController / OrderController ... 이런식으로 세세하게 나누는 게 좋을까?
도메인이 하는 역할이 명확하고, 서로 겹치는 기능이 없다면 세세하게 분리하는 것이 좋을 것이고, 그것이 아니라면 계층으로 나누는 것이 관리하기 편할 듯 하다. 서로 장단이 있지 않을까? 내 경우에는 상품정보를 저장하는 기능과 저장된 상품을 주문하는 기능이 서로 겹치는 부분이 상품 정보를 제외하면 없을 것 같으니 분리하는게 좋을 듯하다.
지금부터 해야 할 일!!
Controller에서 Service에게 일을 시키려면... (== Service의 000를 호출하려면)
Service에서 Respository에게 일을 시키려면.. (== Respository의 000를 호출하려면)
우리는 Controller와 Service가 직접 ㅁㅁ를 생성하는 것이 아니라, 스프링에게 000을 주입해달라고 대신 요청할 것임!! >>> 이게 의존성 주입이다. 어려운 말로 쓸 필요 없음!
DI를 구현하는 방법 3가지
1️⃣ 필드에 어노테이션 사용하기
필드 위에 @Autowired
@Autowired 어노테이션: 자동으로 의존성을 주입하는 어노테이션. 이 어노테이션이 붙은 필드나 생성자의 매개변수를 기준으로, 스프링 컨테이너에서 해당 타입의 빈을 찾아 자동으로 주입한다.
장점 :: 다른 두 방법에 비해 코드 복잡도가 높다.
단점 :: 런타임에 의존성을 결정하고 주입하는 유연성을 제공한다.
2️⃣ 생성자 사용하기
필요한 의존성을 모두 포함하는 클래스의 생성자를 만들고 그 생성자를 넘겨주어 의존성을 주입한다. 즉, 클래스의 생성자에 파라미터로 의존할 객체의 레퍼런스를 넘겨주는 방식이다.
장점 :: 객체의 의존성을 외부에서 전달할 수 있기 때문에 테스트하기 쉬운 코드를 작성할 수 있다.
단점 :: 의존성이 없는 객체를 생성할 때마다 새로운 객체를 만들어야 한다.
3️⃣ Setter 사용하기
의존성을 입력받는 setter 메소드를 만들고 이를 통해 의존성을 주입한다. 즉, 객체의 프로퍼티를 통해 의존성을 주입하는 방법. 객체를 생성한 후, 의존성을 설정할 수 있는 setter 메서드를 호출하여 객체를 초기화하는 방식이다.
장점 :: 객체 생성과 의존성 주입을 분리하여 코드 유지보수성을 향상시킬 수 있다.
단점 :: 코드 가독성이 좋지 않고, 객체의 의존성을 외부에서 전달하는 것이 어려울 수 있다.
JPA 인터페이스의 어노테이션을 사용해서 의존성을 주입하는 것이 가장 바람직하지 않을까 생각이 든다. 런타임에 의존관계를 설정할 수 있으니까?
참고 : https://velog.io/@gillog/Spring-DIDependency-Injection-%EC%84%B8-%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95 , https://www.nextree.co.kr/p11247/ , https://martinfowler.com/articles/injection.html?ref=nextree.co.kr
