DTO <->Entity 변환. converter? vs toEntity(), toDTO()?

#
이를 지원하는 많은 라이브러리들이 있지만 라이브러리의 기술을 제대로 알지 못하면 사용하지 않는다는 생각때문에 귀찮아도 코드로 구현하려 한다.

 

1. 처음에는 DTO - Entity 변환하는데 converter를 사용하려 했다. 근데 그것보다는 static으로 함수를 만드는게 더 깔끔하다는 생각을 했다. DTO-Entity변환 메소드를 컨트롤러의 파라미터에 자동 바인딩을 사용해야하는 것도 아니라서 굳이 converter로 구현할 필요가 없다고 생각했다. 그리고 converter로 다 작성하면 너무 많은 converter가 생겨서 딱봐도 뭔가 잘못된거 같은 느낌이 들었다. 관리비용이 너무 많이 들 것 같은 느낌..

Entity 클래스에 toEntity()를 , DTO클래스에 toDTO()를 Static 메소드로 구현한다. 여기서도 static으로 구현하는 것이 중요한데 이렇게 하면 스프링에 의존적이지 않고 테스트 할 때도 빈주입을 고려할 필요 없다. 그리고 무엇보다 객체를 생성하지 않고 함수를 사용할 수 있다. static을 처음 배울 때 멤버를 사용하지 않고 단순 기능제공이면 static으로 선언하라고 배웠다. 이런 의미에서 보면 실제로 static이 아닌 메소드는 생각보다 작다. static으로 작성하면 나중에 함수형 프로그래밍에서도 함수를 넘길 때 객체를 생성하지 않고 요긴하게 쓸 수 있기 때문에 static으로 만드는 것을 추천한다.

 

#
그리고 DTO클래스에 toEntity()를 만드는 것이 아니라 DTO에는 public static DTO toDTO(Entity entity). Entity클래스에는 public static Entity toEntity()로 구현해야 코드의 역할 분배가 잘 된 것이라는 의견을 들었다. 생성하는게 Entity니까 역할분배의 관점에서 이게 맞는 것 같다.

 

#

만약 @RequestParam등에서 사용해야한다면 converter로 구현하는게 이득일 것임.!

근데 Entity는 service까지만 나갈 수 있으니까 service에서 변환함수를 작성하는 것도 괜찮을듯. 위와 같이 하면 어디서든지 Entity를 만들 수 있잖아!

-> DTO, Entity로 static으로 만드는게 더 좋다.