Enthusiasm! Enthusiasm!

스프링 MVC구조에 대해 배우며 어느 정도 이해를 했고, 직접 코드를 작성하여 구조를 만들어 보니 스프링에서 실제로 어떻게 적용되고 있는지 궁금하였다. 이번 포스팅은 직접 스프링 라이브러리를 들여다보며 MVC 구조를 분석한 글이다. 서론 - 스프링 MVC 구조 다음은 스프링 MVC의 완성된 구조도이며, Sprign boot를 통해 프로젝트를 만들 때, Spring Web 의존성을 추가했다면, 다음과 같이 spring-webmvc라는 이름의 모듈이 라이브러리에 추가되어 있다. 각 구성요소의 역할과 실제 어떻게 구현되어 있는지 알아보자. DispatcherServlet Spring MVC, as many other web frameworks, is designed around the front control..

HttpServletRequest 서블릿은 개발자가 HTTP요청 메시지를 편리하게 사용할 수 있도록, 메시지를 파싱하고 그 결과를 HttpServletRequest 객체에 담아서 제공한다. HttpServletRequest는 start-line 정보, 헤더 정보, 기타 정보 등의 정보를 기본으로 제공한다. 또한 HTTP 요청 데이터를 조회하는 기능도 제공한다. HttpServletRequest가 어떻게 요청 데이터를 조회하는지 알아보자. HTTP 요청 데이터 HTTP 요청 메시지를 통해 클라이언트에서 서버로 데이터를 전달할때는 주로 다음과 같은 3가지 방법을 사용한다. GET - 쿼리 파라미터 사용 /url?username=hello&age=20 메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함..

웹 서버, 웹 애플리케이션 서버 웹 - HTTP 기반 HTTP 메시지에 모든 것을 전송한다. (HTML,TEXT,이미지,음성,파일,API…) 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용한다. 웹 서버(Web Server) HTTP 기반으로 동작 정적 리소스 제공, 기타 부가기능 정적 HTML, CSS, JS, 이미지, 영상 ex) NGINX, APACHE 웹 애플리케이션 서버(WAS - Web Application Server) HTTP 기반으로 동작 웹 서버 기능 포함+ (정적 리소스 제공 가능) 프로그램 코드를 실행해서 애플리케이션 로직 수행 동적 HTML, HTTP API(JSON) 서블릿, JSP, 스프링 MVC ex) 톰캣(Tomcat) Jetty, Undertow 웹 서버, 웹 애플..

HTML폼의 두가지 전송 방식 일반적으로 파일을 업로드 할 때 HTML폼 전송 방식을 사용한다. 파일 업로드 방법을 이해하기 위해서 폼을 전송하는 다음 두 가지 방식의 차이를 이해해야 한다. application/x-www-form-urlencoded multipart/form-data application/x-www-form-urlencoded 방식은 폼 데이터를 서버로 전송하는 가장 기본적인 방법이다. 데이터로는 보통 문자가 사용되며 HTTP Body에 &로 데이터를 구분하여 전송한다. 하지만 파일을 업로드 하려면 바이너리 데이터를 전송해야한다. 또한 파일만 업로드 하는게 아닌 문자와 함께 전송해야하는 상황이 대부분이다. 이 상황을 해결하기 위해 HTTP 에서는 multipart/form-data 전..

애플리케이션을 개발하다 보면 문자를 숫자로 변환 하거나 숫자를 문자로 변환하는 것 처럼 타입을 변환해야 하는 경우가 많다. 빈번이 일어나는 타입변환은 스프링에서 기본으로 제공하지만, 개발자가 만든 타입을 다른 타입으로 변환해야 하는 경우도 있다. 이럴때 마다 개발자가 직접 하나하나 타입 변환을 해야 한다면, 개발의 효율이 상당히 떨어질 것이다. 이와 같은 문제를 스프링에서 어떻게 편리하게 해결 할 수 있는지 알아보자. 타입 컨버터 - Converter public interface Converter { T convert(S source); } 스프링은 위와 같이 확장 가능한 Converter 인터페이스를 제공한다. 이 인터페이스는 모든 타입에 적용할 수 있고, S타입을 T타입으로 변환한다. 양방향으로 변..

정상호출이 되는 상황을 잘 구현하는 것도 중요하지만 실무에서는 상당히 다양한 예외가 발생하기 때문에 이를 처리하는게 더 어려운 과정일 수 있다. 다양한 예외에 대해서, 클라이언트가 잘못하여 발생한 에러인지, 서버에서 발생한 에러인지 구분하여 사용자에게 잘 전달할 수 있어야 한다. 스프링에서 예외처리를 위해 어떤 기능을 제공하는지 포스팅 하겠다. 우선 스프링이 아닌 순수 서블릿 컨테이너가 예외를 어떻게 처리하는지 간단히 알아보자. 서블릿의 예외 발생과 오류페이지 요청 흐름 1. WAS(여기까지 전파) 컨트롤러(/error- page/500) -> View 서블릿이 제공하는 DispatcherType을 이용하면 필터 및 인터셉터의 중복 호출은 막을 수 있다. 하지만 WebServerCustomizer 를 만..

스프링 인터셉터가 필요한 상황 로그인 한 사용자만 특정 페이지에 접근할 수 있도록 설계를 해야하는 상황이라 가정하자. 컨트롤러에서 각 URL마다 로그인 여부를 체크하는 로직을 하나하나 작성하는것은 중복이 많고, 추후에 변경이 있을 시 모든 로직을 수정해야하는 불편함이 있다. 이렇게 애플리케이션 여러 로직에서 공통으로 관심이 있는 것을 공통 관심사(cross-cutting)이라 한다. 이는 스프링의 AOP로도 해결 할 수 있지만, 웹과 관련된 공통 관심사는 서블릿 필터 또는 스프링 인터셉터를 사용하는 것이 좋다. 서블릿 필터 서블릿 필터를 적용하면 필터가 호출 된 다음에 서블릿이 호출된다. 필터의 흐름은 다음과 같다. HTTP 요청 -> WAS -> 필터(필터1,필터2,...) -> 서블릿 -> 컨트롤러 ..

다음과 같은 요구사항이 있는 상황에서 컨트롤러를 설계한다고 가정하자. Item도메인 id: Item마다 가지고 있는 고유의 값으로, 상품을 등록하면 서버에서 생성해준다. id로 상품을 구분하기 때문에 상품 수정 시 반드시 필요하다. ItemName: 상품의 이름으로 null값과 공백을 허용하지 않는다. price: 상품의 가격으로 null값과 공백을 허용하지 않으며, 범위는 1,000~1,000,000까지 허용된다. quantity: 상품의 수량으로 null값과 공백을 허용하지 않으며, 범위는 최대 9999까지 허용된다. 단, 한번 등록 후 수정 시에는 수량의 제한은 없다. 수량*가격은 10000보다 커야한다. 서버측에서는 사용자가 위 조건에 만족하는 값을 전달했는지 반드시 검증해야하며, 여러가지 검증법..