led

Client 요청이 들어오면 등록된 Filter를 거친다. 필터를 거친 후 디스패처서블릿이 요청을 받게된다. 디스패처서블릿은 URL과 요청정보를 가지고 핸들러 매핑으로부터 핸들러(컨트롤러)를 얻어낸다. 이후 등록되어있는 핸들러 인터셉터의 preHandle 메소드를 실행한다. 메소드 실행 이후 컨트롤러가 실행된다. 컨트롤러를 통해 모델과 뷰 정보를 디스패처 서블릿에게 전달하는데 이 중간에서 핸들러 인터셉터의 postHandle 메소드가 실행된다. 메소드 실행 이후 디스패처서블릿은 건네받은 뷰 정보를 가지고 뷰 리졸버로부터 뷰를 얻어낸다. 뷰로 결과를 만들어 응답한다.

핸들러 매핑의 역할 URL과 요청 정보로부터 컨트롤러 빈을 찾아준다. DispatcherServlet으로부터 매핑 작업을 요청받으면 그 결과로 핸들러 실행 체인(HandlerExecutionChain)을 돌려준다. 이 핸들러 실행 체인은 하나 이상의 핸들러 인터셉터를 거쳐서 컨트롤러가 실행될 수 있도록 구성되어 있다. 인터셉터(Interceptor)란? DispatcherServlet에서 Handler(컨트롤러)를 호출하기 전과 후에 request와 response를 참조하거나 가공할 수 있는 일종의 필터다. 서블릿 필터와 쓰임새가 유사하기 때문에 둘 중 어떤것을 사용할지 신중히 선택해야한다. 컨트롤러에 공통적으로 적용할 부가기능이라면 핸들러 인터셉터를 사용하는 것이 좋다. 서블릿 필터와 차이점 Http..

DB driver, url, username, password 를 properties 파일에 넣고 @Value 어노테이션을 이용하여 값을 불러오게 하여쓴데 자꾸 Cannot load JDBC driver class '${..이름..}' 에러가 발생했다. 콘솔에 찍어보니 driverClassName를 포함한 properties에 등록한 값을 못가져오고 있었다. 알고보니 properties를 불러오는 코드를 config파일에 넣어주지 않아서 생기는 에러였다. @PropertySource에 properties 경로를 추가해주니 properties 값들을 잘 가져왔다. @Configuration @PropertySource("classpath:application.properties") @EnableTransa..

MVC는 프레젠테이션 계층의 구성요소 정보를 담은 모델M, 화면 출력 로직을 담은 뷰V, 그리고 제어 로직을 담당하는 컨트롤러C로 분리하고 이 세가지 요소가 협력하여 하나의 웹 요청을 처리하고 응답을 만들어내는 구조이다. MVC 아키텍처는 보통 프론트컨트롤러 패턴과 함께 사용된다. 프론트컨트롤러는 요청request를 받아 공통적인 작업을 먼저 수행한 후 세부 컨트롤러로 작업을 위임해주고 client에게 보낼 뷰를 선택해 최종 결과를 생성하고 만약 예외가 발생했을때 일관된 방식으로 처리하는등의 작업을 수행한다. 스프링 서블릿/MVC의 핵심은 DispatcherServlet이라는 프론트 컨트롤러다. DispatcherServlet은 MVC 아키텍처로 구성된 프레젠테이션 계층을 만들 수 있도록 설계되어 있다...

애플리케이션 코드를 작성할 때, 특정기능이 필요하면 라이브러리를 호출하여 사용하곤 한다. 프로그램의 흐름을 제어하는 주체가 애플리케이션 코드가 된다. 하지만 프레임워크 기반의 개발에서는 프레임워크 자신이 흐름을 제어하는 주체가 되어 필요할 때마다 애플리케이션 코드를 호출하여 사용한다. 프레임워크에서 이 제어권을 가지는 것이 바로 컨테이너(Container)다. 객체에 대한 제어권이 개발자로부터 컨테이너에게 넘어가면 객체의 생성부터 생명주기 관리까지의 모든것을 컨테이너가 도맡아서 하게된다. 이를 일반적인 제어권의 흐름이 바뀌었다고 하여 IoC 제어의 역전이라고 부른다. 컨테이너란?(Container) 컨테이너는 인스턴스의 생성부터 소멸까지 생명주기를 관리하며, 생성된 인스턴스에게 추가적인 기능을 제공한다...