인프런 커뮤니티 질문&답변

@ModelAttribute의 유무와 상관없이 결국 ArgumentResolver가  매개변수를 생성하는 것은 같습니다. 

적절한 생성자가 있다면 Setter는 아예 없어도 되었구요.

또한, 리플렉션을 통해 별도의 설정을 하고 강제로 접근하고 있었기 때문에 생성자의 접근제한자는 private이여도 아무 문제 없었습니다. 

결국 @ModelAttribute가 달려있어서 바뀌는것은 ModelAndView를 View에 바인딩하느냐 아니냐 정도의 차이인 것 같고, 그러니 SSR이 아닌 CSR 방식을 사용하게 되면 ModelAndView를 아예 신경쓰지 않아도 될 것이고, 이렇게 되면 @ModelAttribute를 달았을 때 오히려 성능상 손해를 보는것이라고 생각했습니다.

어차피 별도의 View 페이지를 사용하지 않기 때문에 ModelAndView를 세팅하는 작업들이 쓸데없다고 생각됐기 때문입니다.

 

그런데 또 가만 보니 @ModelAttribute가 달려있다면 ArgumentResolver들이 들어있는 일급컬렉션에서 매우 높은 우선순위를 갖고 처리되기 때문에 후속 루프가 모두 생략되는 장점이 있고, @ModelAttribute가 없다면 매우 낮은 우선순위를 갖고 처리되기 때문에 순회를 훨씬 더 많이 하더라구요.

이럴거면 굳이 ModelAttributeMethodProcessor에 상태값을 줘서 두개로 나누기보다 그냥 하나로 합치는게 더 낫지않았을까? 라는 생각이 들었는데, 스프링 설계자들은 대체 어떤 큰 그림을 그리며 이런 구조를 채택했을지가 너무 궁금했습니다. 분명 어떤 이유가 있을 것 같은데 제 수준으로는 짐작가는게 없네요.. 😭

안녕하세요. 한창훈님

저도 잘 모르겠네요^^;

혹시 아시는 분 있으면 답변 부탁드립니다.

감사합니다.