-
질문 & 답변
카테고리
-
세부 분야
백엔드
-
해결 여부
미해결
memberUpdateDto가 필요한 이유
22.12.11 12:27 작성 조회수 325
0
강의도중에 설명해주시긴 했는데 그래도 이해가 덜 가서 질문드립니다
membersaveDto만있으면 memberupdatedto를 만들지 않아도돼요
둘다 만들게 되면 코드의 중복이 발생하는것아닌가요?
save와 update는 아예다른것이기때문에 중복이 발생해도 상관이 없는걸까요?
아예다른것이라기엔 update에도 있고 save에도 있는 필드에 변화가 생겼을때 둘다 수정을 해주어야해요
그럼 수정해야할 포인트가 늘어나는건데도 updateDto를 생성해주는게 맞는걸까요?
답변을 작성해보세요.
0
OMG
2022.12.11
당장은 한두개 일지만 우리가 만드는 프로그램이 커지고 비즈니스 요구사항이 늘어날 수 있다고 한다면, 분리하는게 맞다고 생각합니다.
실용적인 관점과 비즈니스적인 관점을 잘 파악하셔서 설명드린 대로 클래스 이름은 포괄적이게 하여 재사용하거나, 분리할지를 판단하셔야 할 것 같습니다.
답변에서 말씀드린 것처럼 혼자 개발한다면 실용적인 측면에서 재사용해도 될 것 같습니다. 하지만 누군가에게 보여줘야하거나(포트폴리오), 같이 협업을 한다면(그리고 내가 개발하고 나서 누군가가 내 코드를 유지보수 할 수 있음을 고려한다면) 클래스를 분리하여 내가 개발한 규칙을 알려주지 않아도 알 수 있게 클래스를 분리해서 개발 할 것 같습니다.
OMG
2022.12.11
조금 더 확장해서 생각하면, 당장 memberDTO는 공통으로 사용하지만, item, order 등 다른 도메인에서 복잡한 로직으로 인해 분리해야 한다면, 그래서 item은 update와 save를 분리한다면 그것도 우리 프로그램의 개발 관점에서 보면 통일성이 떨어질 수 있는 것이여서
(잘못된 것은 아니지만) 이러한 상황도 고려해 볼 법하여 말씀드립니다.
0
OMG
2022.12.11
혼자 개발한다면 saveDTO를 저장에 쓰건, 업데이트할 때 쓰건 개발 자체에는 문제 되지 않겠지만, 협업을 한다면 명시적이고 실제 객체의 역할에 맞는 클래스 이름을 사용하시길 권장드립니다.
update와 save 둘 다 사용한다면 기존 클래스 이름을 가져가는 것 보다는 memberDto 혹은 memSaveAndUpdateDto가 더 나을 것 같습니다.
저장과 수정에 사용되는 필드가 동일하다면 위에서 설명드린 것과 같이 하셔도 되겠지만, 복잡한 실무상황에서는 등록과 수정에 필요한 필드가 다를 수 있습니다.
[예시] 가령 등록에서는 유저 아이디{
식별자의 id가 아닌 minjikim123과 같은} 를 입력 받지만, 수정에서는 유저 아이디를 변경할 수 없다는 정책이 있다면 유저 아이디 필드는 dto에 포함하지 않아도 됩니다.
이러한 상황에서는 dto를 분리하시면 될 것 같습니다.
.
감사합니다.
답변 2