작성
·
60
·
수정됨
0
멤버 업데이트 시
memberService.update(id, request.getName());
으로 작성해 주셨는데
memberService.update(id, request);
와 같이 객체를 통째로 넘기지 않는 이유가 있는 것인가요?
위와 같이 객체를 통째로 넘기는 경우 UpdateMemberRequest 클래스를 이너 클래스가 아닌 별도의 클래스로 분리해 줘야 하는 게 맞나요?
답변 1
0
안녕하세요. gnstjrdlsla님, 공식 서포터즈 y2gcoder입니다.
저는 UpdateMemberRequest 는 2가지 이유로 MemberService.update()에 인자로 넘기지 않을 것 같습니다!
request의 모든 파라미터가 필요한 게 아니기 때문입니다. 현재 update 로직에서는 name만 변경하고 있기 때문에 그보다 많은 파라미터를 가진 request를 통째로 넘길 필요가 없습니다. 부수적으로 필요한 파라미터만 넘기는 것이 테스트 코드를 짤 때도 테스트에 필요한 객체를 만들 때 더 쉬웠습니다 🙂
유지보수 관점에서 request를 바로 넘기지 않는 것이 더 좋을 것 같다고 생각하기 때문입니다. (해당 이유가 본론이라고 생각합니다!) request는 웹 계층에서 요청 파라미터를 받아 매핑한 객체입니다. 이를 서비스 단까지 넘기면 해당 객체는 경우에 따라 서비스 단의 로직까지 여기에 의존할 수도 있습니다(비즈니스의 유효성 검사 등). 비즈니스 단의 로직까지 해당 객체에 의존하게 되면 해당 객체를 수정하려고 할 때마다 두 계층 모두 테스트해야 합니다. 이는 단순히만 따져도 2배로 체크해야 하는 일입니다 🙃 결론을 말씀드리자면 기존에는 웹 -> 비즈니스 간의 단방향 의존성이었다면 웹 계층의 객체를 비즈니스 계층의 객체가 의존하는 순간 웹 <-> 비즈니스 간의 양방향 의존성이 생기게 됩니다. 이는 위에서 말씀드렸던 하나의 예시 이외에도 유지보수 과정에서 예상치 못한 문제를 발생시킬 수 있습니다!
위의 두가지 이유에서 저는 request를 그대로 서비스 로직에 넘기는 것을 권하지 않습니다 🙂
추가로 말씀해주신
위와 같이 객체를 통째로 넘기는 경우 UpdateMemberRequest 클래스를 이너 클래스가 아닌 별도의 클래스로 분리해 줘야 하는 게 맞나요?
는 말씀하신 방향대로 하시는 것을 권합니다! 🙂
감사합니다.