안녕하세요! 사이드 프로젝트 중 궁금한점이 생겨 질문 남깁니다! 최근 팀원분께서 validation 의존성을 추가하여 회원가입 시 프론트와 백 둘다 검증하기 위해 컨트롤러에서 검증까지 추가하셨습니다! 여기서 드는 의문점이 컨트롤러가 이러한 검증 로직까지 가지고 에러를 반환하는것이 맞을까라는 생각이 들었습니다 그렇다고 서비스 로직이라고 판단하기도 어려워 AOP나 인터셉터를 사용해 분리하는게 먖을까 고민중에 댓글 남깁니다! 현업에서는 어떻게 사용하는지, 제가 컨트롤러라는 책임에 너무 매몰되어잇는건지 궁금합니다!
컨트롤러 단에서도 검증을 하는 것은 적절할 수 있습니다. 예를들면 특정 필드의 최대 길이, 최소 길이, 포멧 같은 경우는 백엔드에서도 데이터의 유효성 검증을 해야하는 경우가 상당합니다 (모든 경우는 아닙니다) 백엔드에서 검증을 안하고, 데이터 저장을 그대로 해준다면 이는 DB단의 오염도 증가까지도 생기기도 합니다. 개인적으로 validation을 추가하는 것도 좋지만 테스트 코드로 검증이 더 쉬운 명시적 코드 방식의 검증도 좋다고 생각합니다. 또, 케이스마다 다르지만 AOP나 인터셉터를 사용하는 것은 과할때가 많은 것 같습니다, 마법처럼 숨겨져서 동작하게 되면 추후에 복잡도를 뒷 사람들이 감당해야할 수 있더라구요 그래서 조금 더 생각을 넓히셔서 다음 레이어로 넘겨주기 전에 데이터를 온전하게 만들고 넘겨주는 관점으로 레이어간 검증을 명확히 한다고 생각해보시면 좋을 것 같습니다.
안녕하세요! 사이드 프로젝트 중 궁금한점이 생겨 질문 남깁니다! 최근 팀원분께서 validation 의존성을 추가하여 회원가입 시 프론트와 백 둘다 검증하기 위해 컨트롤러에서 검증까지 추가하셨습니다! 여기서 드는 의문점이 컨트롤러가 이러한 검증 로직까지 가지고 에러를 반환하는것이 맞을까라는 생각이 들었습니다 그렇다고 서비스 로직이라고 판단하기도 어려워 AOP나 인터셉터를 사용해 분리하는게 먖을까 고민중에 댓글 남깁니다! 현업에서는 어떻게 사용하는지, 제가 컨트롤러라는 책임에 너무 매몰되어잇는건지 궁금합니다!
컨트롤러 단에서도 검증을 하는 것은 적절할 수 있습니다.
예를들면 특정 필드의 최대 길이, 최소 길이, 포멧 같은 경우는 백엔드에서도 데이터의 유효성 검증을 해야하는 경우가 상당합니다 (모든 경우는 아닙니다)
백엔드에서 검증을 안하고, 데이터 저장을 그대로 해준다면 이는 DB단의 오염도 증가까지도 생기기도 합니다.
개인적으로 validation을 추가하는 것도 좋지만 테스트 코드로 검증이 더 쉬운 명시적 코드 방식의 검증도 좋다고 생각합니다.
또, 케이스마다 다르지만 AOP나 인터셉터를 사용하는 것은 과할때가 많은 것 같습니다, 마법처럼 숨겨져서 동작하게 되면 추후에 복잡도를 뒷 사람들이 감당해야할 수 있더라구요
그래서 조금 더 생각을 넓히셔서 다음 레이어로 넘겨주기 전에 데이터를 온전하게 만들고 넘겨주는 관점으로 레이어간 검증을 명확히 한다고 생각해보시면 좋을 것 같습니다.
@@geminikims 답변 너무 감사합니다! 별거 아닌거 같은데 이걸로 2-3일 고민하고, 디른 방법도 찾아보려했는데 생각보다 이런 내용은 잘 다루지않는거같더라구요 제가 검색 능력이 부족한것 같습니다ㅋㅋ 다시한번 답변 감사드립니다!
LikeEventPublisher는 같은 도메인계층에 만드는걸까요?
비즈니스 레이어의 비즈니스 로직 안에서 동작하는 상황일때 구현 계층에 만들어진다고 보시는게 더 정확한 것 같습니다!
잘봤습니다
봐주셔서 감사합니다!
1빠. 항상 감사합니다.
무려 1빠!! 봐주셔서 감사합니다!
2빠. 사랑해요
무려 2빠!! 봐주셔서 감사합니다!