그런 바리케이드는 많을 수록 좋긴한데, 로그인이나 회원가입 같은 경우라면 프론트 단에서 한번, 그리고 service랑 Cont 단에서도 해야겠지
루리에a(cong0114)2024-08-06 11:01
답글
그다지 중요하지 않은 거라면 바리케이드는 그렇게 많이 치지 않는게 좋음..
루리에a(cong0114)2024-08-06 11:01
답글
아니면 테이블 설계 단계부터 비교할 수 있는 데이터를 여러개 집어넣거나 기타 등등 방법은 많다
루리에a(cong0114)2024-08-06 11:03
어디서 하든 일관성 있게 하셈 여기서 했다가 저기서 했다가 하지말구 - dc App
익명(59.12)2024-08-06 11:11
validation api 검색
파라미터 검증을 컨트롤러나 서비스단에서 지져분해짐
가끔 가다 디비 조회 등이 필요한 경우가 있는데, 그건 예외
익명(211.249)2024-08-06 11:39
프론트에서 기본적인 validation 다 처리
백엔드 컨트롤러에서 dto로 요청받을때 2차 검증
서비스에서 비즈니스로직 처리할때 3차 검증
익명(223.62)2024-08-06 12:16
레이어마다 역할이 달라
프론트 validation은 사용자 편의를 위해 있다고 생각하면 돼, 서버 입장에서는 없는거나 마찬가지임
서버 입장에서 보자면, 포맷이나 필수값 여부, 길이나 크기 제한 등을 체크하려면 컨트롤러 레벨에서 validation api 적용해서 처리하는게 좋음
나머지는 상황에 따라 달라
그런 바리케이드는 많을 수록 좋긴한데, 로그인이나 회원가입 같은 경우라면 프론트 단에서 한번, 그리고 service랑 Cont 단에서도 해야겠지
그다지 중요하지 않은 거라면 바리케이드는 그렇게 많이 치지 않는게 좋음..
아니면 테이블 설계 단계부터 비교할 수 있는 데이터를 여러개 집어넣거나 기타 등등 방법은 많다
어디서 하든 일관성 있게 하셈 여기서 했다가 저기서 했다가 하지말구 - dc App
validation api 검색 파라미터 검증을 컨트롤러나 서비스단에서 지져분해짐 가끔 가다 디비 조회 등이 필요한 경우가 있는데, 그건 예외
프론트에서 기본적인 validation 다 처리 백엔드 컨트롤러에서 dto로 요청받을때 2차 검증 서비스에서 비즈니스로직 처리할때 3차 검증
레이어마다 역할이 달라 프론트 validation은 사용자 편의를 위해 있다고 생각하면 돼, 서버 입장에서는 없는거나 마찬가지임 서버 입장에서 보자면, 포맷이나 필수값 여부, 길이나 크기 제한 등을 체크하려면 컨트롤러 레벨에서 validation api 적용해서 처리하는게 좋음 나머지는 상황에 따라 달라