값을 검증하는 위치는 어디가 좋을까?

프로젝트를 진행하며 값 검증 위치에 대해 고민했던 내용인데요, DTO에서 @Validation 을 사용해 값을 검증하는 방법을 바꾸고자 했던 내용입니다. 정답은 없기 때문에 하나의 의견으로 읽어주시면 감사하겠습니다. JPA를 사용했기 때문에 글을 읽기 위해서는 JPA에 대한 기본적인 이해가 필요합니다. 

 

 

 

 

 

 

1. DTO에서 값 검증

---

엔티티를 생성하기 위해 값을 DTO에서 검증할 수 있습니다. 이는 아래와 같은데요, 클라이언트로부터 받은 값을 어노테이션을 통해 검증하는 것입니다. 컨트롤러에서 @Valid 어노테이션을 사용해야 하지만 어노테이션을 통해 값을 간편하게 검증할 수 있습니다. 

 

 

 

 

 

 

 

하지만 아래와 같은 몇가지 의문점이 들었습니다. 였습니다. 요구사항이 바뀌면 DTO를 재활용할 수도 없으며 매번 조건을 변경해줘야 하기 때문입니다. 또한 DTO는 값을 전달하기 위한 역할을 지니는데 이렇게 되면 값을 전달하면서 검증까지 해야하는 책임이 생기고, 무엇보다 DTO를 위한 테스트코드를 따로 작성하기도 애매했습니다. 

 

    - 만약 한 화면에 대한 명세가 바뀐다면 유연하게 대처할 수 있을까?

    - 검증 조건이 까다롭다면 어노테이션이 많이 달리게 될텐데 이것을 한 눈에 알아볼 수 있을까?

    - DTO가 값을 검증하는게 맞는 것일까? 

 

 

 

 

 

2. 값 객체를 통한 검증

---

그래서 값 객체를 사용해 객체 내부에서 값을 검증하는 방법을 사용했는데요, 엔티티 내부에 @Embedded로 값 객체를 만들어  내부에 검증할 조건을 두는 것입니다.

 

 

 

 

 

 

이렇게 되면 값 객체에서 값을 검증하기 때문에 변경사항이 발생하더라도 이 한 곳만 바꿔주면 되고 객체를 재활용할 수 있습니다. 또한 DTO도 굉장히 간단해지는데 아래와 같이 검증을 위한 어노테이션이 사라지고 온전히 값을 전달하는 역할만 할 수 있습니다. 

 

 

 

 

 

 

무엇보다 테스트코드를 작성하기 쉬워지는데 값 객체는 재활용할 수 있기 때문에 테스트코드를 작성하기가 쉽습니다. 

 

 

 

 

 

 

 

3. 단점

---

물론 단점도 존재합니다. 대표적으로 값 객체를 생성하는 과정에서 오류를 알 수 있다는 점과 프로젝트가 복잡해진다는 점입니다. 값 객체를 생성하는 과정에서 오류를 알 수 있다는 것은 아래와 같이 생성자를 호출해야 한다는 점인데요, 생성자를 호출하고 그 과정에서 예외가 발생하기 때문에 추가적인 비용이 발생합니다. 

 

 

 

 

 

 

또한 JPA를 사용하게 되면 protected 이상의 기본 생성자를 반드시 가져가야 한다는 점과 값 비교를 위해 Equals & HashCode를 재정의해줘야 하는 문제도 있습니다. 

 

 

 

 

 

 

무엇보다 프로젝트가 복잡해진다는 점이 가장 큰 문제점인데요, 이는 크게 Getter 사용, 객체 그래프 탐색에서 나타납니다. Getter를 사용할때 래퍼 클래스를 사용했기 때문에 값 객체 내부와 엔티티 모두 Getter 메서드를 정의해줘야 합니다.

 

 

 

 

 

 

뿐만 아니라 객체 그래프 탐색을 할때도 아래와 같이 한 번 더 객체를 탐색해야 합니다. 많은 이점이 있지만 이처럼 Getter 사용, 프로젝트의 복잡도 증가와 같은 단점도 분명히 존재합니다.

 

원래대로라면 study.comment만 하면 되지만 study.comments.comment와 같이 한 번더 .을 찍어줘야 합니다.

 

 

 

 

 

4. Conclusion

---

모든 값들을 래퍼 클래스로 포장하고, @Embedded 어노테이션을 사용하는 것은 그렇게 일반적이지 않기 때문에 팀원들과의 협의가 필요할 것 같습니다. 이 부분만 협의가 된다면 변경점을 줄일 수 있고 검증을 위한 많은 어노테이션을 생략할 수 있기 때문에 꽤 괜찮은 방법이라 생각이 듭니다. **항상 생각하지만 코드에 정답은 없기 때문에 자신의 상황에 맞는 방법을 적용하면 될 것 같습니다.