[Spring Boot - 🐱PetClinic🐶] 8. Controller 분석(1)🔍

쑤밍·2023년 4월 18일

[Spring Boot - 🐱PetClinic🐶]

목록 보기

8/11

✔️ Controller 공통사항

처리하는 경로의 수가 많은 컨트롤러엔 공통으로 리턴하는 페이지의 이름을 private static final String으로 선언해 둔다. (OwnerController, PetContoller)

private static final String VIEWS_OWNER_CREATE_OR_UPDATE_FORM = "owners/createOrUpdateOwnerForm";

모든 컨트롤러는 데이터베이스 관련 기능을 수행할 Repository 객체를 생성자에서 주입받는다.
@InitBinder 어노테이션이 붙은 메서드가 있다.
@ModelAttribute 어노테이션이 붙은 메서드가 있다.

💉 Controller의 Repository 객체 의존성 주입

지금까지 내가 사용했던 의존성 주입은 Repository 객체건 Service 객체건 모두 빈으로 등록하고 @Autowired 어노테이션을 이용해 Controller에서 주입받는 방식을 사용했다. 그런데 Pet Clinic에서는 그 대신 변수를 private final로 선언하고 생성자에서 객체를 할당받는 방식을 사용했다.

private final OwnerRepository owners;

public OwnerController(OwnerRepository clinicService) {
	this.owners = clinicService;
}

그냥 했을 것 같진 않고 뭔가 이유가 있으리라 생각해서 찾아봤다. 의존성 주입 방법에는 크게 세 가지가 있다고 한다. 첫 번째로는 필드 주입 방식, 두 번째로 수정자 주입 방식, 마지막으로 생성자 주입 방식이 있다.

1. 필드 주입 방식

이 방식은 내가 주로 사용했던 방식이다. 위의 코드를 필드 주입 방식으로 바꾸자면

@Autowired
private OwnerRepository owners;

이런 코드가 될 것이다. Controller에 주입할 빈 객체는 따로 빈 객체라고 등록해야 주입할 수 있다. 코드가 간결하다는 장점이 있으나 추천하는 방식은 아니라고 한다. 필드 주입을 통해 의존성을 주입하게 되면 외부에서 수정이 불가능하고, 테스트 케이스를 작성할 때 객체를 수정할 수 없기 때문이다. 필드 주입을 통해 의존성을 주입한다면 final 키워드를 통한 선언이 불가능하기 때문에 객체가 mutable 해진다. 또한, 의존성 주입을 남발하게 될 수 있기 때문에 단일 책임의 원칙을 위배할 수 있기 때문에 사용을 지양해야 한다.

2. 수정자 주입 방식

이 방식은 Setter 메서드를 통해 객체를 주입받는 방식이다. 위의 코드를 수정자 주입 방식으로 바꾸자면

private OwnerRepository owners;

public setOwnerController(OwnerRepository clinicService) {
	this.owners = clinicService;
}

이런 코드가 될 것이다. Setter 메서드는 관계를 주입받는 객체의 변경 가능성이 있기 때문에 필요한 경우만 사용해야 한다. 하지만 보통의 경우 객체가 변경될 일이 없기 때문에 사용할 일이 드물다. 변경 가능성을 열어두게 되면 오류가 발생할 위험이 높기 때문에 사용을 지양해야 한다.

3. 생성자 주입 방식

이 방식은 생성자를 통해 객체를 주입받는 방식이다. 맨 처음에 소개한 코드가 생성자 주입을 사용한 코드이다. 생성자는 객체가 생성될 때 한 번만 호출되는 특성이 있기 때문에 immutable 하다. final 키워드로 선언할 수 있다. 이 방식은 주입받은 객체가 불변이어야 하거나, 반드시 객체의 주입이 필요한 경우 사용하게 된다. 다른 방식들은 Spring과 같은 프레임워크에서 동작하기 때문에 테스트 코드를 작성하기 까다롭다. (의존성 주입을 프레임워크에서 담당하는데 테스트 코드는 프레임워크에서 동작하는 것이 아니기 때문) 하지만 생성자 주입 방식을 이용한다면 테스트 코드 작성이 쉽다. 또한 개발자의 실수로 순환 참조를 하게 될 경우 다른 방식들은 런타임 에러가 나는 반면 생성자 주입 방식은 컴파일 에러가 나기 때문에 에러를 수정하기 더 좋다.

각자의 장단점이 있지만 생성자 주입 방식이 장점이 조금 더 많기 때문에 생성자 주입 방식을 사용하는 것이 좋을 것 같다. 추가로 롬복(Lombok)의 @RequiredArgsConstructor 어노테이션은 생성자를 작성하지 않아도 알아서 만들어 주기 때문에 사용하기 편리하다. 롬복을 사용하기 위해서는 객체를 주입할 변수를 final로 선언하고 그 위에 위의 어노테이션을 붙여주면 된다.

📚 @InitBinder

@InitBinder는 생소한 어노테이션이었다. 지금까지 (많이 해본 건 아니지만) 진행했던 프로젝트에서는 컨트롤러의 구성을 데이터베이스 관련 서비스 객체가 있고 @GetMapping이나 @PostMapping의 어노테이션들을 사용해서 경로 설정을 해주고 경로에 대한 처리를 어떻게 할지 코드를 작성하는 게 다였다. 이 어노테이션이 어떤 역할을 하고 어떻게 사용하는지 궁금해서 찾아봤다.

@InitBinder 어노테이션은 @Controller나 @ControllerAdvice 클래스가 가질 수 있고, WebDataBinder를 초기화한다. 쉽게 말해 클라이언트로부터 들어오는 리퀘스트 파라미터를 모델 객체에 바인딩한다는 의미이다. 모든 요청 전에 @InitBinder가 붙은 메서드를 실행한다고 한다.

setAllowedField와 setDisallowedField를 통해 허용할 필드, 허용하지 않을 필드를 설정할 수 있다. addCustomFormatter를 통해 필드의 형식을 지정할 수도 있다. 또한, addValidators를 통해 유효성 검증을 할 수 있다. 이 밖에도 여러 메서드가 있어 여러 설정 사항을 지정할 수 있다.

Pet Clinic에서는 setDisallowedField와 addValidators를 사용하고 있다. addValidators는 왜 쓰는지 이해가 가는데 setDisallowedField는 왜 사용하는지 이해가 안 가서 찾아봤는데 다들 사용법만 알려주고 왜 쓰는지는 알려주지 않는다. 왤까...? 아이디 필드는 요청이 들어와도 서버에서 결정하는 값이기 때문에 그런가..? 아무튼 @InitBinder는 더 찾아봐야 할 것 같다.

📚 @ModelAttribute

지금까지 봤었던 @ModelAttribute 어노테이션은 메서드의 파라미터로 주어지는 값에 붙어있는 경우만 봤었다. 하지만 Pet Clinic에서 사용하는 것은 메서드 앞에 붙어있었다. 이는 @InitBinder과 마찬가지로 요청이 들어왔을 때 @ModelAttribute가 요청 처리 전 먼저 실행된다. @InitBinder가 들어오는 객체를 담을 때 사용한다면 @ModelAttribute는 메서드의 반환 값을 클라이언트에 보낼 model 객체에 담는 역할을 한다.

🧩 마무리

Controller들을 보며 생소한 개념들을 정리하다 보니 글이 길어졌다. Pet Clinic의 Controller 분석은 다음 글에서 할 예정이다. 객체에 의존성을 주입할 때 생성자 방식을 사용하는 것이 장점이 많다는 것을 알게되어 좋았다. 그런데 @InitBinder는 유효성 검사 외엔 어떤 이유로 사용하는지 아직 감이 안 와서 더 알아봐야 할 것 같다.