메시지, 국제화 소개 메시지 코드에 직접 적힌 코드를 일일이 수정하는 것은 보통일이 아니다. 만약 기획자가 html의 라벨 속 상품명 이란 단어를 모두 상품이름으로 변경해 달라고 하면 어떻게 해야할까? 일일이 고치면 될 것 같아 보이지만, 많은 코드들을 실수없이 변경하
loginDTO, membetDTO를 나누는게 더 좋나? (비밀번호를 암호화 할 정도로) 보안에 신경쓰는데, 그냥 SELECT * 해서 member의 비밀번호를 다 가져오고 그러는건 좀 아니지 않나? 로그인 처리하기 - 쿠키사용 로그인 상태 유지하기 로그인의 상태를
요구사항에 따르면, 로그인을 한 사용자만 상품 관리 페이지에 접근할 수 있다. 그러나 지금까지 우리가 작성한 코드는 URL을 직접 호출하는 경우 상품 관리화면에 접근 가능하다. (단순히 버튼을 보여주지 않는 방식으로 구현했기 때문에)이는 모든 컨트롤러 로직에서 일일이
프로그램을 개발하고 사용하는 과정에서 예상하지 못한 여러 오류 발생할 수 있다. 예외 발생 시 사용자에게 오류 페이지를 제공하는 것 또한 주요한 구현 사항 중 하나이다. 이같은 오류 페이지 관련 메커니즘을 서블릿과 스프링이 어떤 방식으로 제공하고 있는지 알아보자! 서
검증 요구사항 요구사항: 검증 로직 추가 타입 검증 가격, 수량에 문자가 들어가면 검증 오류 처리 필드 검증 상품명: 필수, 공백X 가격: 1000원 이상, 1백만원 이하 수량: 최대 9999 특정 필드의 범위를 넘어서는 검증 가격 * 수량
소개 검증기를 일일이 매번 작성하는 것은 상당히 번거로운 일이다. 특히 특정 필드에 대한 검증 로직은 '값이 비었는지', '특정 범위 안인지'와 같이 매우 일반적인 로직이다. 이런 로직들을 애노테이션화 해서 아래와 같이 간단히 줄일 수 있다. 너무 좋다 이런 검증
시작 > 목표 API 예외 처리는 어떻게 해야할까? HTML 페이지를 통해 오류 페이지를 제공하는 것은 간단한 해결방법이다. 오류 페이지는 단순히 사용자에게 오류 화면을 제공하고 끝이 난다. 그에 비해 API 경우에는 고려해야 할 부분이 훨씬 늘어난다. API는