해결된 질문
작성
·
355
0
강의에 나온 내용은 아니지만 개인적으로 개발을하다 궁금한 점이 생겨서 질문 드립니다.
조회 API를 만들 때 (GET요청)Controller단에서 파라미터를 받는 방식이 @RequestParam, @ModelAttribute 크게 2가지 있는데 2가지 방식중 어떤 방식을 선호하지는지 질문드립니다.
@RequestParm을 사용했을 때는 Controller단에서 바로 직관적으로 어떤 파라미터를 받는지 확인이 가능하다는 장점이 있지만 Service단으로 파라미터를 넘겨줄 때, 하나하나 넘겨줘야해서 파라미터가 추가되었을 때 불편하다는 점이 있을 테고
@ModelAttribute를 사용했을 때는 수정에는 유리하겠지만 가독성은 떨어질 것 같다는 생각이 듭니다.
강사님은 어떤 생각을 가지고 계신지, 현업에서는 주로 어떤방식으로 개발을 하는지 의견주시면 감사하겠습니다.
답변 2
1
안녕하세요, psam1017 님!
저는 @ModelAttribute
를 선호합니다. 이유는 크게 2가지 인데요.
강의에서 보여드린 것처럼 파라미터 검증에 대한 책임과, 최소한의 가공 책임을 가질 수 있는 공간이 생깁니다.
Controller에서 이를 담당한다면 책임이 분산됩니다.
해당 로직에 대해 보다 쉬운 단위 테스트도 가능합니다.
실무에서는 API가 조금만 복잡해져도 파라미터가 수십개가 넘어가므로, 모든 필드를 하나하나 @RequestParam
으로 선언하기가 현실적으로 어렵습니다.
도움이 되셨기를 바랍니다.
감사합니다~! 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
@RequestParam
과 @ModelAttribute
는 사용하는 상황과 선호에 따라 선택할 수 있습니다. 두 어노테이션은 목적이 다르기 때문에 선호도를 논하기 전에 각각의 사용 목적을 알고 사용하는 것이 중요합니다.
@RequestParam
은 주로 단일 파라미터를 처리할 때 사용되며, 간단한 HTTP 요청 파라미터를 메소드 파라미터로 쉽게 가져올 수 있는 장점이 있습니다. 파라미터가 적고, 관리가 간편할 때 유용합니다. URL 쿼리 파라미터가 직관적으로 컨트롤러 메소드에 매핑되므로 API 문서를 작성하거나 API의 사용성을 논할 때 가독성이 좋습니다.
반면, @ModelAttribute
는 요청 파라미터를 객체로 바인딩해주어 복잡한 객체를 만들어야 하는 경우에 유용합니다. 특히 도메인 객체나 DTO(Data Transfer Object)를 사용할 때 객체의 프로퍼티에 자동으로 바인딩되므로, 다수의 파라미터를 한 번에 처리할 수 있으며 파라미터 추가나 변경이 있을 때 유연하게 대응할 수 있습니다.
현업에서는 상황에 따라 두 방식을 적절히 혼합해서 사용합니다. 파라미터가 많고 복잡한 경우 @ModelAttribute
를 통해 객체로 바인딩하고, 간단한 파라미터 처리가 필요할 때는 @RequestParam
을 사용하는 경향이 있습니다. 유지 보수성, 가독성, 그리고 API를 사용하는 클라이언트와의 커뮤니케이션 측면을 고려하여 상황에 맞는 방법을 선택하는 것이 좋습니다.
강의 내용과는 직접적인 관련이 없지만, 체계적인 테스트 프로세스를 구축하는 데 있어서도 이러한 설계 결정이 중요할 수 있으며, 각 방식별로 테스트 케이스를 만들고 관리해야 할 것입니다.