현재 실무에서 리팩토링 중인 소프트웨어는, 기존에는 모든 검색기능이 POST 메소드의 API를 통해 서버에서 data를 불러와 client단에서 화면이 렌더링 되도록 설계되어 있었다.
파라미터가 너무 많은 경우 쿼리스트링을 쓰지 않고 request body에 json으로 파라미터들을 때려박던 것으로 시작해 소프트 웨어 내의 모든 조회 기능이 그렇게 구현된 것 같았다.
팀장님은 기존의 방식은 url에 검색 조건이 남지 않으니, url에 검색 조건이 남도록 전부 바꾸자고 하셨다.
url에 사용자가 요청한 검색조건을 남기려면 기존의 방식을 버리고 GET메소드를 통해 서버단에서 렌더링된 HTML을 내려받는 방식으로 변경해야 했다.
검색 조건이 많지 않은 경우 parameter로 곧바로 받으면 됐지만, 조건이 너무 많은 경우 파라미터만으로도 controller가 너무 지저분해지고 가독성도 떨어져 파라미터에 객체를 사용해야 했는데
이는 고맙게도 Spring MVC가 Request Param을 파라미터에 위치한 객체로 자동 변환해주는 덕분이다.
늘 그렇듯 이 기능을 편하게 사용하던 중 이상하게 한 객체만 매핑이 안된다;
도대체 뭐가 잘못됐는가 한참을 삽질했는데, 이 매핑이 안되는 DTO는 기본생성자가 있었다.
기본생성자가 있으면 매핑 가능한 데이터가 있어도 Spring이 그냥 빈 객체만 생성해서 넘겨주는 것이었다. 왜? setter가 없어서 ㅠ. 알고나니 당연한 사실인데 왜 그렇게 안보였던 것인가
모든 필드를 받는 생성자도 있어서 알아서 매핑해주겠거니 생각했는데 기본 생성자가 우선이었고, setter가 없어서 빈 객체만 리턴하는 것이었다.
참고로 모든 필드를 다 받는 생성자만 쓰는 경우 값이 없는 필드가 있더라도 알아서 빈 값(null)로 매핑해주니 NoArgsConstructor와 Setter를 굳이 사용하지 않아도 AllArgsConstructor만으로도 데이터 매핑이 가능하다
결론 -> AllArgsconstructor만 쓰거나 or NoArgsConstructor + Setter를 쓰거나
