인프런 커뮤니티 질문&답변
작성한 질문수
데이터 검증 로직 책임에 대한 질문이 있습니다.
해결된 질문
작성
·
38
1
안녕하세요.
정말 재밌게 수강중입니다.
다름이 아니라 데이터 검증 책임에 대해서 궁금한게 있습니다.
저는 사용자에 의해 넘겨받은 데이터를 Controller 에서는 값의 존재여부와 타입 정도만 확인하고 실제로 비즈니스 레이어에서 사용될 때 검증하는 것을 선호하는데, 강의에서는 Request(DTO) 객체에서 toContent() 함수를 호출하면서 검증하더라구요.
특별히 Request 에 위치시킨 이유가 있을까요?
관점이 궁금합니다.
fun toContent(): QuestionContent {
if (title.isEmpty()) throw CoreException(ErrorType.INVALID_REQUEST)
if (title.length > 100) throw CoreException(ErrorType.INVALID_REQUEST)
if (content.isEmpty()) throw CoreException(ErrorType.INVALID_REQUEST)
return QuestionContent(title = title, content = content,)
}
해당 로직이 아래 방식으로 들어가는게 책임이 맞지 않을까? 라는 생각입니다.
data class QuestionContent(
val title: String,
val content: String,
) {
init {
if (title.isEmpty()) throw CoreException(ErrorType.INVALID_REQUEST)
if (title.length > 100) throw CoreException(ErrorType.INVALID_REQUEST)
if (content.isEmpty()) throw CoreException(ErrorType.INVALID_REQUEST)
}
}
답변 2
0
안녕하세요! 질문 감사드립니다!
이 부분은 딱 이것이 정답이다! 는 어렵지만 저는 Request에서 처리하는 것을 선호하고 대부분 옳다라고 보는 편입니다!
제 관점은 해당 코드 검증 로직은 누구의 책임인가를 좀 더 면밀히 보는 편입니다
isEmpty 와 length 같은 부분은 API 스펙과 연관이 있다고 생각합니다 (물론 비어있지 않음이나 길이의 대한 검증은 자기 자신의 책임이라고 볼 수 있지만 생성하는 쪽에서도 책임이 있다고 보는 편입니다)
개념 클래스가 맡아야하는 것 이전에 API 요청 자체가 잘못 되어 있는 것을 검증하는 것이니 Request 레벨에서 온전히 검증을 끝내고 정상적인 개념 객체를 생성해주는 것 까지 맡아줘야한다고 생각하는 편 입니다
추가로 저는 개념 클래스 들이 가급적 단순한 형태면 좋다고 생각합니다 (그렇다고 코드를 아예 안 넣자는 의미는 아니고 "본질적으로 가장 중요하고 해야하는 일을 가지고 있으면 좋겠다~" 정도입니다)
그 측면에서는 개념 클래스들이 생성 될때 이미 충분히 검증 된 상태로 생성 될 수 있다면 가장 좋다고 생각합니다
다만 A 개념 객체 -> B 개념 객체로의 전환이 일어난다면 이것에 대한 추가 검증 로직은 당연히 개념 객체가 책임을 가지고 있어야겠죠!
모쪼록 답이 되었길 바랍니다! 완강 후 수강평도 기대하겠습니다!
추가 질문은 언제나 환영입니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. parksj914님.
데이터 검증 로직의 책임을 어디에 둘 것인가에 대한 고민은 개발 설계 시 중요한 주제 중 하나입니다. 본래의 목적은 코드의 가독성과 유지보수성을 높이며, 각 계층의 역할을 명확히 하는 것입니다.
Controller vs. DTO/도메인 객체에서의 검증
Controller에서 검증:
- 장점: 빠르게 사용자 입력에 대한 기본적인 검증을 처리하여 시스템 내부로 잘못된 데이터가 들어가는 것을 방지할 수 있습니다.
- 단점: 로직이 복잡한 경우, Controller가 너무 무거워질 수 있습니다.
- 장점: 빠르게 사용자 입력에 대한 기본적인 검증을 처리하여 시스템 내부로 잘못된 데이터가 들어가는 것을 방지할 수 있습니다.
DTO에서 검증하는 경우:
- 장점: DTO 레벨에서 입력값의 유효성을 검증함으로써, Controller의 책임을 줄입니다.
- 단점: DTO가 많은 검증 로직을 가지면서 원래의 데이터 전달 역할이 불분명해질 수 있습니다.
- 장점: DTO 레벨에서 입력값의 유효성을 검증함으로써, Controller의 책임을 줄입니다.
도메인 객체에서 검증하는 경우:
- 장점: 도메인 객체는 자기 자신을 스스로 검증할 수 있는 책임을 가짐으로써 상태 불변성을 보장할 수 있습니다.
- 단점: 불필요한 객체 생성이 증가할 수 있으며, 일부 검증은 시스템의 다른 부분에서 이미 해결될 가능성이 있습니다.
- 장점: 도메인 객체는 자기 자신을 스스로 검증할 수 있는 책임을 가짐으로써 상태 불변성을 보장할 수 있습니다.
강의에서 아마도 Request(DTO) 객체에서 검증을 수행하는 이유는 입력의 일차적인 유효성 검사를 통해 빠르게 문제를 검출하고, 도메인 객체로의 변환 전에 데이터를 최소한으로 검증을 완료하기 위한 설계일 수 있습니다. 이렇게 하면 도메인 객체를 만드는 시점에서는 데이터가 확실히 유효하다는 가정 아래 작업할 수 있습니다.
각 접근 방식은 장단점을 가지고 있으며, 프로젝트의 규모나 팀의 표준에 따라 선택이 달라질 수 있습니다. Controller에서 비즈니스 로직 흐름이 나타나는 것에 대하여.. 관련된 주제에 대한 논의가 있는 게시물을 참고하시면 선택 시 고려할 요소에 대해 더 깊이 이해할 수 있을 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변 감사합니다.
질문을 작성할땐 몰랐는데 답변을 받아보니 저의 생각을 잘못 작성한것같습니다.
isEmpty(), length 의 경우 API 스펙이기 때문에 Request 가 담당하는것에 공감합니다.
추가 검증로직에 대해서 질문을 드리려고 했는데 의도를 잘못전달했습니다.
다행스럽게도 강사님께서 답변을 주신것 같습니다.
다음에 또 다른 질문으로 찾아뵙겠습니다. 감사합니다.