인프런 커뮤니티 질문&답변
작성한 질문수
@RequestMapping 활용
해결된 질문
작성
·
477
1
안녕하세요 Controller의 경로를 보고 /user /book 부분이 중복된다고 생각하였습니다.
혹시 @RequestMapping을 활용해서 중복을 제거하지 않으신 이유가 있으신가요?
답변 2
0
역시나 친절한 답변 감사드립니다.
편리하게 사용하기 위해 중복을 제거하는것이 오히려 단점이 될 수 있는 상황도 존재하는군요
또한 version control diff를 많이 고려하신다는게 느껴지시네요 ㅎㅎ
그 이유가 혹시 코드리뷰등을 수행할때 변경지점을 한눈에 알아보기 쉽게 하려는 의도신가요?
0
안녕하세요! j님~~~ 크~~ 역시 좋은 질문이십니다 ㅎㅎㅎㅎ
안그래도 이 내용은 <25강. 유저 대출 현황 보여주기 - 프로덕션 코드 개발>에서 다루고 있습니다!!! 😊
해당 강의에서는 중복을 제거하지 않은 이유를 API가 수십개, 수백개 되었을 때 보다 쉽게 검색하기 위해서라고 언급하고 있는데요!!! (API URL을 관리하는 몇 가지 방법도 함께 소개해드립니다 ㅎㅎㅎㅎ)
강의에서는 구성상 말씀드리지 못했던 내용도 조금 더 말씀드리자면,
(이 경우는 적지만) 추후에 URL에 변경이 일어날 경우, 그 지점을 최소화하기 위함도 있습니다!
예를 들어, AController에 "/a"로 시작하는 7가지 API가 있다고 해보겠습니다! 그래서 Controller Class 단에 RequestMapping을 사용해 중복을 제거 했습니다!
그러던 어느날, 그 중에 2가지 URL을 변경해야 하는데 "/a" 로 시작하면 안되게 변경해야 합니다. 하지만 동시에 A 도메인과 관련된 기능이기 때문에 AController에 위치시키는 것이 팀 컨벤션 입니다.
이 경우에 중복을 제거하기 위해 Class 단에 RequestMapping이 있다면, 이것을 제거하고 7개 API URL을 모두 수정해야 합니다.
하지만, 애당초 Class 단이 아니라 Method 단마다 URL을 지정해주었다면, 정말 필요한 2가지 URL만 변경이 되겠죠! (trailing comma와 비슷한 효과라고 생각해주시면 이해가 더욱 잘 되실 것 같습니다~!! 👍👍)
추가로 비슷한 이유로 @Transactional 역시 저는 개인적으로 Method 별로 붙여주는 것을 선호합니다! readOnly 옵션은 DB HA 구성을 위해 필요한 경우 잘 붙여주어야 하는데, Class 단으로 붙이면 실수할 여지도 많고, 변경이 일어났을 때 여러 군데 한 번에 변경되는 것이 조금 불편하더라고요!
물론, 제 개인의 취향이 반영된 부분이고, 사람마다 가치에 대한 의견이 다를 수 있어 (나중에 분리되더라도 지금 중복을 제거하는게 더 가치있다고 생각할 수 있죠!!!) 팀끼리 잘 정하면 되는 부분이라고 생각합니다!! 😊😊
정리 드리자면, 1) API가 수십개, 수백개로 늘어났을 때 검색을 쉽게 하기 위해서 2) 변경시 version control diff를 최적화 하기 위해서 Method 단위로 사용하였습니다!
크으~~~ 좋을 질문 감사드립니다 ㅎㅎㅎㅎㅎ
오늘 연휴도 행복하고 소중한 하루 되세요~!!! 🙏
편리하게 사용하기 위해 중복을 제거하는것이 오히려 단점이 될 수 있는 상황도 존재하는군요
--> 네네 맞습니다 ㅎㅎㅎㅎ
코드 리뷰의 용이성도 물론 있지만, 그보다는 새로운 요구사항을 추가할 때 변경 지점을 최소화하는 것을 조금 더 신경쓴다고 생각해주시면 될 것 같습니다 ㅎㅎㅎ
이게 참 어려운 부분이긴 합니다~ 같은 것을 같게~ 다른 것을 다르게~ 해야 하는데 추후에 다르게 발전할 수 있는 부분은 지금은 같아보이고 중복이 제거되더라도 중복해서 가지고 있는 경우가 좋았던 경험이 꽤 있어서요!