Valitator vs Exception 처리
Validation 적용 회고에서 다양하게 Validation을 적용했었는데, 주요한 포인트는, 간단한 것은 BeanValidation으로, 복잡한 것은 Validator 구현으로 하자였다. 그런데, 작업하다보니 복잡한 경우,
Validation 적용 회고에서 다양하게 Validation을 적용했었는데, 주요한 포인트는, 간단한 것은 BeanValidation으로, 복잡한 것은 Validator 구현으로 하자였다. 그런데, 작업하다보니 복잡한 경우,
온라인 도서관에 파일 전송 기능을 추가하려고 하고 있는데, 도서 등록 기능은 현재 RestApi로 하고 있었다. form 태그를 사용하면, 단순히 enctype=”multipart/form-data”
스프링 인터셉터는, 서블릿 필터와 같이 컨트롤러 이전에 필터링을 하는 기능이다. 서블릿 필터가 HTTP 요청 -> WAS -> 필터 -> 서블릿
기존에는 로그아웃시에도 세션이 생성되는 비효율적인 작업이 존재했다. 이렇게 되면, 로그아웃을 시도하면서 빈 세션을 생성하게 된다. request와 SessionAttribute 사용 로그아웃시에는 request.getSession(false)를
Optional 기존 코드는, 아래와 같은 식으로 직접 Repository에서 요소를 반환하도록 되어 있었다. 이 경우, null 처리를 하는데 번거로움이 존재한다. Optional을
각각 Validator에서 처리 기존에는 책을 찾지 못하는 오류를, 아래와 같이 처리했었다. 이 경우, id라는 필드에 매핑하고 있었다. 이 방법도 나쁘지는
기존에, FrontControllerServlet 아키텍쳐에서 SpringMvc 아키텍쳐로 전환하면서, 프로젝트 구조를 도메인 주도 설계 구조로 전환한 바 있다. 하지만, 이를 한 번 더
김영한 스프링 mvc2편의 Validation을 보며, 순차적으로 Validation을 적용해보았다. Validator부터, restApi에 Validator 적용, BeanValidation을 동시에 적용해서 Validator에 복잡도를 줄이는 방식까지 최종적으로
@ModelAttribute에 BeanValidation 적용에서 ModelAttribute로 적용은 매우 쉽게 했다. 그런데, RestApi에 적용은 어떤 식으로 하면 좋을까? RestApi는 매우 복잡한 방식으로 메시지