인프런 커뮤니티 질문&답변
작성한 질문수
컨트롤러의 파라미터로 Pageable를 직접 받을까요 혹은 page, size, sort등을 따로 받을까요?
해결된 질문
작성
·
521
0
안녕하세요!
컨트롤러의 파라미터로 Pageable을 직접 받을 수 있으나 @PageableDefault로는 1가지 기준으로만 정렬이 가능한 것 같은 제약사항이 있는 것으로 알고 있습니다.
@SortDefault로 여러개의 정렬 조건을 추가할 수 있다고는 하나 파라미터에 어노테이션이 너무 많아지나..? 싶기도 합니다.
또 만약 page라는 변수명이아니라 pageNo처럼 다른 변수명을 사용할 때의 유연성을 위해서라도 Pageable 인터페이스로 직접 받기보다는 페이징의 각 요소를 받아서 PageRequest 객체를 따로 생성하는 것이 더 나을까요?
토이프로젝트보다 훨씬 복잡한 상황의 현업환경에서는 어떤 방식이 더 자주 사용되는지 궁금합니다!
답변 2
1
안녕하세요. 자프링님
실무에서도 간단한 상황에서는 기존 것을 사용하지만, 상황이 복잡해지면 말씀하신 것 처럼 직접 PageRequest를 생성해서 사용하는 경우가 많습니다.
비슷하게 팁을 알려드리자면 프로젝트를 진행하는 모든 부분에서 기존 것을 최대한 활용하는 것이 좋지만, 우리 프로젝트에 맞지 않는다면, 기존 것을 너무 잡고 있는 것 보다는 우리에게 맞는 방식을 사용하는 것이 더 좋습니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴이에요. 컨트롤러의 파라미터로 Pageable을 직접 받을지, 아니면 page, size, sort 등을 따로 받을지에 대해 궁금하시네요.
첫 번째로, Pageable 인터페이스를 컨트롤러의 파라미터로 직접 받는 방법과 @PageableDefault를 사용하여 정렬 기준을 설정하는 방법이 있는데요. @PageableDefault로는 한 가지 기준으로만 정렬할 수 있다는 제약사항이 있습니다. 이 경우, 여러 개의 정렬 조건이 필요한 상황에서는 @SortDefault를 사용하여 추가적인 정렬 조건을 지정할 수 있습니다. 그러나, 이렇게 파라미터에 적용되는 어노테이션이 많아지면 가독성이 떨어지는 문제가 있을 수 있습니다.
두 번째로, 다른 변수명을 사용할 때의 유연성을 위해 Pageable 인터페이스로 직접 받는 대신, 페이징의 각 요소를 받아서 PageRequest 객체를 따로 생성하는 방법을 사용하는 것도 고민해볼 만합니다. 이 방식을 사용하면 변수명에 제약이 없어지기 때문에 더 유연하게 사용할 수 있습니다.
실제 현업 환경에서는 어떤 방식이 더 자주 사용되는지에 대해서는 일반화하기 어렵습니다. 각각의 프로젝트나 상황에 따라 다르게 사용될 수 있는데요. 토이 프로젝트에서는 가독성이나 유연성을 우선시하여 더 편한 방식을 선택하시는 것이 좋습니다. 그리고 실제 현업 환경에서는 프로젝트의 규모와 요구사항에 따라 선택하게 될 것입니다.
결론적으로, 파라미터로 Pageable을 직접 받을지 아니면 Pageable 인터페이스로부터 PageRequest 객체를 생성하여 사용할지는 개인의 선호나 프로젝트의 규모와 요구사항에 따라 다를 수 있습니다. 사실, 어느 쪽을 선택하더라도 동작하는 것은 동일하기 때문에, 편한 방식을 선택하시면 될 것 같아요. 좋은 개발 경험이 되시길 바랄게요!
감사합니다!!