[ 들어가기 전에 ] 앞의 1편부터 3편까지의 글을 작성하면서 컨트롤러에서 공통적인 로직을 처리하기 위해서 필터로 로깅이나 인증/인가를, 검증을 따로 지원하는 javax.validation을 사용해서 컨트롤러와 분리하는 방법에 관해서 알아보았다. 이제는 컨트롤러 단에서 예외가 발생했을 때 어떻게 처리해야 하는가에 관해서 이야기를 해보고자 한다. 우선 이걸 알아보기 전에 컨트롤러에서 예외를 일으켜보고 응답을 보면서 시작해보자. @GetMapping("/controller/exception") public void exception(){ throw new IllegalArgumentException(); } 위의 코드를 포스트맨을 통해서 작동시켜보면 아래와 같이 에러가 뜰 것이다. 분명히 아무런 작업을 해주..

[ HTTP 요청과 검증 처리 ] HTTP로 요청이 날아오면 컨트롤러에서는 보통 쿼리 파라미터, 바디, 헤더, 쿠키의 4가지 값들을 처리한다. 이게 가능한 이유는 Dispatcher Servlet 때문이며 그 안에는 HTTP 메시지 컨버터와 요청 매핑 핸들러 어댑터로 애노테이션에 따라 적절한 컨버터와 핸들러를 매칭하기 때문이다. 그래서 컨트롤러에서는 딱히 파라미터의 순서, 파라미터 종류에 관해서 웬만한 게 다 있다. 예를 들어, 가게의 이름과 가격을 통해 검색을 하는 상황이 있다고 해보자. 이 때, 쿼리 파라미터 값이 들어오지 않거나, 쿼리 파라미터 값이 int 타입인데 값이 범위를 지나거나 하는 경우, 예외를 처리해주어야 한다. 이 예외처리는 어디에서 해줘야할까? 아마 검증에 관해서 모른다면 다음처럼 ..

[ 필터 ] 필터는 스프링의 프론트 컨트롤러인 Dispatcher Servlet에 요청이 도달하기 전 URL 패턴에 맞는 모든 요청에 대해 부가작업을 처리하는 기능을 제공한다. 해당 코드를 작성한 사람이 남긴 목적에 의하면 총 9가지 용도로 세분화해서 사용할 수 있다고 적혀있다. 하지만 요약해보면 데이터 압축 및 변환, 로그인 인증 및 인가, 로그 이렇게 3개로 요약이 가능할 것 같다. 아래의 코드는 Filter 인터페이스에 코드로 메서드는 총 3가지가 있다. 그런데 init이나 destory를 써본 적이 없다. 생성자 주입 방식으로 필요한 객체를 주입 받는 방식을 보통 사용했었기 때문이다. 그래서 제일 중요한 메서드는 doFilter인데 외부의 request 요청 값을 받아 여러 처리를 하여 쓰레드 로..

[ 컨트롤러의 역할 분리에 관해 알아야 하는 이유 ] 스프링 MVC를 가장 먼저 배웠을 땐 컨트롤러 계층에서의 스프링 MVC 중요성을 잘 이해하지 못했다. 왜냐하면 단순히 요청만 받고 응답만 내보내면 된다고 생각했기 때문이다. 특히나 처음 프로젝트를 진행했을 때에는 프로젝트에서 구조가 컨트롤러는 서비스를 위임받고 서비스는 리포지토리를 위임받은 구조에 가까웠다. 그러다보니 중요성을 잘못 느꼈다. 그런데 이번에 우빈님의 테스트 코드 강의를 듣고 내 개인 프로젝트에 그 내용을 적용시키는 과정에서 한계를 부딪혔다. 코드를 작성하면서 나는 과연 각각의 역할을 적절하게 잘 분리하고 있나라는 의문이 들었다. 테스트 코드를 작성하고 생각을 해보며 스프링 필터랑 인터셉터가 언제 시작되고 검증 부분은 누가 어떻게 실행하고..

보호되어 있는 글입니다.

보호되어 있는 글입니다.