inflearn logo
강의

Course

Instructor

Web Programming Using Spring Boot: This is How You Build a Website!

Applying JPA to Member Service CRUD - II: Creating EntityManager

DTO 관련

Resolved

97

jsshin

2 asked

0

강의 열심히 듣고 있습니다.

 

다름이 아니라, DTO 관련 의구심이 들어서 질문 올립니다.

 

선생님께선 modifyConfirm 일때

dto의 pw 값을 encode된 값으로 변경하셔서 entity로 넣으셨는데,

String encodedPW  = passwordEncoder.encode(memberDTO.getPw());
memberDTO.setPw(encodedPW)

findedMemberEntity.setMemPw(memberDTO.getPw());

 

위의 방법대로 하면,

dto값이 변경이 되어 "단순 전달 객체"를 위배할 수 있으며, 간결성과 가독성이 떨어지는게 아닌가 싶어서요

 

아래와 같이 리펙토링 하면 조금 더 간결하게 되지 않을까요?

if (optionalMember.isPresent()) {
    MemberEntity findedMemberEntity = optionalMember.get();
    findedMemberEntity.setMemPw(passwordEncoder.encode(memberDTO.getPw()));
    ~~
    return MODIFY_SUCCESS;
}

rest-api spring-boot jpa spring-security mybatis

Answer 2

0

blogstudy0222

jsshin님 안녕하세요.^^
아주 좋은 질문입니다. DTO는 계층 간 데이터를 전달하는 객체로서, 원칙적으로는 값을 변형하지 않는 것이 설계적으로 더 깔끔합니다.

현재 코드처럼 memberDto의 pw 값을 passwordEncoder.encode()로 인코딩한 후 다시 memberDto에 반영하면, DTO가 단순 데이터 전달 객체라는 역할과 조금 어긋날 수 있다는 지적은 충분히 타당합니다.

DTO의 값이 메서드 실행 중에 변경되면, 이후 코드에서 혼란을 줄 수 있고, 코드의 직관성이 떨어질 수 있습니다.

그래서 실무에서는 보통 인코딩된 비밀번호를 별도의 변수로 관리하거나, DTO → Entity 변환 과정에서 처리하는 방식을 더 많이 사용합니다. 이렇게 하면 코드의 가독성과 안정성이 올라갑니다.

다만, 이번 온라인 강의에서는 스프링 입문자분들께 패스워드 인코딩이 어떤 시점에 이루어지는지 직관적으로 보여드리기 위해 memberDto의 pw를 직접 변경하는 방식을 사용했습니다.

즉, 객체가 한 번 수정되고 그 수정된 값이 저장되는 과정을 명확하게 이해하도록 돕기 위한 교육적인 목적이 있었습니다.

결론적으로 실무에서는 더 깔끔한 설계로 개선할 수 있고, 강의에서는 학습자의 이해를 돕기 위해 일부 의도적인 것입니다.

그리고 이런 부분을 예리하게 캐치해서 질문하고, 직접 리팩토링까지 시도해 본 점은 정말 훌륭합니다. 무한 박수를 보냅니다. 이런 자세야말로 진짜 개발자로 성장하는 최고의 밑거름이고, 객체지향 설계에 대한 매우 훌륭한 감각을 가지고 있다는 증거입니다.


열심히 공부하는 그 자세에 진심으로 감사드리고, 앞으로도 계속 응원하겠습니다.

0

communityai8509

안녕하세요, 인프런 AI 인턴입니다. jsshin님.

DTO(Data Transfer Object)는 본래 데이터를 전송하는 데 사용되는 객체로, 보통은 순수하게 데이터만을 저장하고 전달하는 역할을 합니다. jsshin님께서 제기하신 문제는 DTO의 본래 역할을 벗어나는 것에 대한 우려로써 충분히 타당한 지적입니다.

DTO 역할과 리팩토링 방향

  • DTO의 역할: 데이터 전달만 담당하므로, 암호화나 비즈니스 로직이 DTO에 포함되는 것은 원칙적으로 바람직하지 않습니다.
  • 리팩토링의 장점: jsshin님이 제시해 주신 리팩토링 방식은 DTO의 순수성을 유지하고, 가독성을 높이며 코드의 복잡도를 낮춥니다. 이 방식은 비즈니스 로직을 서비스 계층으로 밀어내어 유지보수성을 높일 수 있습니다.

제안된 방법의 평가

  • 제안된 리팩토링 코드는 비즈니스 로직을 DTO에 넣지 않고, 엔티티에 바로 처리 함으로써 코드를 더 깔끔하고 이해하기 쉽게 만듭니다.
  • 이 방식은 비즈니스 로직과 데이터 전달의 역할을 명확히 구분하고, 여러 부분에서 장점이 있습니다.

관련 논의들은 다양한 포럼과 강의에서 다루어졌으며, 이와 유사한 문제에 관한 설명을 찾아 보시면 더 많은 인사이트를 얻으실 수 있을 것입니다.

이러한 구분은 나중에 프로젝트를 관리하고 확장하는 데 매우 유리하며, 특히 규모가 커질수록 그 중요성이 커집니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

Entity 동등성 비교

0

4

1

패키지 구분에 대해 궁금한게 있습니다

0

12

1

스프링부트 서버 에러나요

0

17

1

2026.04에 추가된 강의 시청 불가

0

28

1

Service Create/Update Record 운용과 Delete Record 미운용의 차이 질문

0

22

1

인가 코드 발급(프론트 vs 백)

0

29

2

인텔리제이 MCP 서버 설정 관련

0

27

1

Dto와 Entity 사용 관련 질문

0

31

2

application.properties 작성 관련 질문

0

46

2

IDE를 Eclipse로 설지해서 수업을 진행해도 되나요

0

70

2

일정 삭제 시 예외 발생 질문과 이전 질문에 대한 추가질문드립니다.

0

78

2

일정 등록 및 조회 부분 강의 질문입니다.

0

75

2

JWT 기반 인증

1

77

2

properties 파일 질문입니다

0

71

1

인터셉터

0

89

2

추가 강의 해주실수 있나요?

0

107

1

데이터베이스 테이블이 중복 생성 되는 오류

0

122

3

mysql 설치파일

0

81

2

dto 타입

0

75

1

로그인 후 (인증완료) /member/modify 접근불가

0

89

2

메일 보내는 메서드에서

0

74

1

인터셉터 질문

0

106

2

AOP에 대한 설명

0

183

2

코드

0

154

1