ModelMapper에 대해 질문드립니다 !!

Question

안녕하세요! 엔티티 -> DTO, DTO -> 엔티티 변환 모두 STRICT 전략을 사용하는 modelMapper.map을 사용하고있습니다. DTO를 쓰는 이유 -> 엔티티가 바뀌어도, dto는 그대로이므로 api 스펙이 바뀌지않음. 그런데 STRICT 전략을 쓰는 modelMapper를 사용하면, dto와 엔티티 필드이름이 정확하게 일치해야하므로 엔티티가 바뀌면 dto 필드도 바뀌어야함. 이렇게 되면 엔티티 변경 시에 api 스펙이 바뀌지않는다는 장점이 없어지게됨 이런 생각이 들었는데, 그럼 STRICT 전략은 지양해야하나요, 아님 다른 방법이 있는 것인가요?

rafaelakutch58 · Answer

Addicted to Incredibox? Sprunki Game is the perfect fix! Play now and start making awesome music!

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. 김지호님, ModelMapper의 STRICT 전략을 사용하는 경우 필드 이름이 정확히 일치해야 하므로 엔티티가 변경되면 DTO도 변경되어야 하는 상황이 발생할 수 있습니다. 이러한 특성을 고려할 때 몇 가지 대안을 제안드릴 수 있습니다. Custom Mappings 사용 : STRICT 모드 대신, custom mappings을 설정하여 필드 이름이 일치하지 않더라도 변환이 가능하도록 설정할 수 있습니다. 이를 통해 엔티티와 DTO의 변경에 유연하게 대응할 수 있습니다. Loose Matching 사용 : ModelMapper의 Loose Matching을 사용하여 필드 이름이 완전히 일치하지 않더라도 변환이 가능하도록 하는 방법이 있습니다. 이 경우, 정확한 일치보다는 유사한 이름을 찾는 방식으로 매핑을 수행합니다. Mapper 라이브러리 변경 고려 : 보다 유연한 매핑이 필요하다면 다른 매핑 라이브러리(Mapping frameworks), 예를 들어 MapStruct를 사용하는 것도 고려할 수 있습니다. MapStruct는 컴파일 타임에 유형 안전하고 성능이 뛰어난 매핑 코드를 생성합니다. DTO 레이어 추상화 : 가능하다면 DTO를 엔티티로부터 더 독립적인 상태로 유지하여 엔티티의 변경이 DTO에 영향을 주지 않도록 디자인합니다. 예를 들어, Service 계층에서 필요에 따라 변환 로직을 추가하여 관리할 수 있습니다. 이 방법들을 검토해보시고, 상황에 맞는 최적의 전략을 선택하시기 바랍니다. 필요에 따라 modelMapper의 기능을 확장하거나 다른 스택을 고려하는 것도 좋은 방법입니다. 추가적인 학습을 위해 Spring Data JPA - Reference Documentation 도 참조해 보시면 도움이 될 수 있습니다.