Entity 메소드 파라미터로 DTO를 받는 것, 괜찮을까요?

답변 감사합니다.

메소드를 호출할때가 아닌, 엔티티 내 메소드 선언부 파라미터 입장에서 생각해보니 이해가 되네요.

부가적인 질문인데요. 혹시 엔티티에 수정해야할 필드 수가 상당히 많은 경우에도, 메소드 파라미터로 모든 필드를 넘겨받도록 코드를 짜는건 회피하기 힘들까요? 

(가령 회원 프로파일의 어트리뷰트가 대략 40-50개 된다는 가정하에..)

또한 40-50개 필드 중, 수정대상이 아닌 경우 기존값을 그대로 주는게 아니라 빈값으로 들어오는 케이스라면 (비즈니스 플로우 상 search 후, 수정/미수정 값 모두 채워서 update를 하는것이 아니고 수정 대상만 채워서 호출)

이 경우 아래처럼 조건문을 다 달다보니 보기에 지저분해보여 보다 깔끔한 패턴이 있을지 고민중에 있습니다.

if(name != null) this.name = name;

좋은 하루 보내세요.

1. Jinseok Han 님의 말씀을 들으니 그 상황이라면 저도 DTO의 사용을 고려해볼 것 같습니다. 대신 DTO를 생성한다면 위치를 엔티티와 같은 패키지에 둬서 패키지의 순환 참조가 일어나지 않게 할 것 같습니다. 

2. 저도 경험이 많지 않아 고민이 되는데요. 직장 동료가 질문을 한다면 JPA를 사용하고 있다면 어차피 dirty checking으로 엔티티를 업데이트할테니 각 필드별로 업데이트 로직을 작성하라고 할 것 같습니다. 그래야 테스트 코드를 짜서 검증할 때 하나씩 해볼 수 있어 더 명확하게 테스트를 할 수 있을 것 같고, 특정 필드를 검증하는 방법을 바꿀 때 좀 더 쉽게 찾을 수 있을 것 같기 때문입니다. 

파이팅입니다.

저도 실력이 많이 부족하지만 혹시나 도움이 될까하여 댓글을 추가로 달아봅니다~!

Jinseok Han 님의 케이스는 하나의 사용자가 가입을 하거나, 해당 사용자가 개인정보를 수정하는 것으로 보입니다.

이 케이스의 경우에는 어쩔 수 없이 거의 모든 파라미터가 해당 Entity 로 매핑이 되는 케이스 인 것 같습니다.

아래와 같은 케이스라면
Class User {

          @Embedded private Contact contact .. 혹은

          @OneToOne? private Contact contact ..

}

객체의 필드를 매핑하는 라이브러리를 사용해서,  아래와 같이 매핑을 하거나, dto 에서 Contact 로 매핑해서

Contact contact = 매핑라이브러리 사용 / Contact contact = dto.toContact()

갱신을 하는 방식을 사용하면 어떨까요?

user.updateContact(매핑라이브러리 사용(dto)); / user.updateContact(dto.toContact());

// 혹은 Contact 라는 객체를 생성하는부분이 복잡한 로직이거나, 외부호출 등 의존성이 필요하다면 팩토리클래스 혹은 팩토리메서드를 만드는것도 고려하실 수 있을 것 같아요

물론 DTO 는 데이터를 전달하는 역할만 수행하는게 맞고, 위에서 말한 dto 를 Contact 로 매핑하는 방식은 올바르지 않을 수 있지만 어느선에서 타협하신다면, Entity 의 update 메소드에서 DTO 를 전달하는 것보다 고수준모듈을 지키는 방식이 되지않을까합니다.

해당 방식을 사용하신다면, Request 의 변화에 대해서 도메인레이어에서는 영향을 받지않는 설계가 가능할 것 같습니다.

저는 개인적으로 DTO 를 Entity 와 같은 패키지에 두는것 보다는, 위처럼 매핑을하는 방식이 더 좋지않을까 생각합니다.

1. DTO 를 바로 전달하게 된다면 위에 설명하신 것처럼 DTO 의 phone 라는 필드가 phoneNumber 로 변경되는 경우, Entity 코드또한 수정이 일어날 수 있다고 생각하고,

2. 등록과 수정에서 다른 DTO 를 사용하신다면 updateContact(RegisterDTO dto), updateContact(UpdateDTO dto) 처럼 update 하는 코드가 지속적으로 늘어날 수 있지않나 하는 우려가 듭니다.

RequestDTO 는 서버와 클라이언트의 규약일 뿐이라고 생각합니다. 따라서 비즈니스의 핵심규약을 모아놓은 도메인레이어에 Entity 와 같이 위치하는 것은 개인적으로 좋은 설계가 아니지 않나 생각이 드네요.. 

제가봐도 글을 잘 못썼지만.. 이해하시는데는 문제가 없지않을까 .. 하네요 T^T

그럼 20000,,

감사합니다.
말씀하신 것처럼 DTO에서 entity로 바로 매핑하는 것도 있는데 그걸 생각못했네요.
저도 DTO에서 entity로 변환해주는 게 좋아보입니다.