- 이제 직접 mvc 프레임워크를 서블릿을 통해 만들어 보겠다.
- 프론트 컨트롤러 패턴 도입전에는 클라이언트가 공통 로직과 컨트롤 로직을 각각 전부 만들어야 했다.
- 그러나 프론트 컨트롤러 서블릿을 도입해 이곳에 공통로직을 돌고 필요한 로직은 각자 처리하도록 할 수 있다.
- 프론트 컨트롤러가 서블릿 하나로 클라이언트의 요청을 받고, 컨트롤러가 요청에 맞는 개별 컨트롤러를 찾아 호출한다.
- 그러므로 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다. 프론트 컨트롤러가 직접 호출해주니까.
- 스프링 MVC의 핵심이 프론트 컨트롤러 패턴이다. 스프링 웹 MVC의 DispathcherServlet이 프론트 컨트롤러 패턴으로 구현되어 있다.
- 앞으로 만드려는 구조다. 클라이언트가 요청을 하면 프론트 컨트롤러 서블릿이 요청을 받는다. 컨트롤러를 url 매핑 정보에 넣어둘 것인데, 프론트 컨트롤러가 매핑 정보를 통해 컨트롤러를 조회 및 호출한다. 해당 컨트롤러에서 로직을 수행하고 jsp로 포워딩할 것이다.
- 먼저 컨트롤러 인터페이스를 만들겠다. 각 컨트롤러들은 이 인터페이스를 구현하면 된다. 프론트 컨트롤러는 구현과 관계없이 이 인터페이스를 호출해 로직의 일관성을 가져간다.
- 먼저 회원 등록 컨트롤러를 만들겠다. 구현 컨트롤러를 controller 패키지 한 곳에 몰아넣을 것이다.
- ControllerV1을 implements 해 구현한다.
- 기존 서블릿 mvc에서 구현한 코드와 같다.
- 마찬가지로 회원 저장 컨트롤러와
- 회원 정보 컨트롤러를 만들어 준다.
- 이제 프론트 컨트롤러를 만들어 보겠다. v1 패키지 하부에 클래스를 만들어 준다.
- urlPatterns 맨 끝의 "*" 은 뒤에 어떤 url 요청이 들어와도 이 컨트롤러를 호출한다는 뜻이다.
- 먼저 매핑 정보를 만들어준다. 키를 url로 하고 밸류를 컨트롤러 V1 으로 할 것이다. 어떤 url이 들어와도 컨트롤러 V1을 호출한다는 뜻이다.
- 생성자를 만들고 매핑 정보를 컨트롤러에 담아준다. "v1/members/new-form"으로 오면 MemberFormControllerV1()을 호출하는 식이다.
- 역시 각각 매핑 정보에 따른 컨트롤러를 호출하도록 구성한다.
- 이제 매핑 정보에서 컨트롤러를 찾고, 호출 후 응답이 jsp로 나가도록 할 것이다.
- GetRequestURI를 사용하면 요청한 URI(ex."/front-controller/v1/members")를 그대로 받을 수 있다.
- 이 URI를 controllerMap.get의 파라미터로 넣어 꺼내면 그 컨트롤러가 반환된다.
- 만약 없을 경우(null)이면 NOT_FOUND_404 에러를 띄우고 리턴한다.
- 잘 조회가 되면 인터페이스를 따라 각 컨트롤러에서 정의한 process를 호출해주면 된다.
- process를 호출하면 이전에 정의해둔 viewPath 경로를 통해 해당 컨트롤러의 jsp로 dispather.forward()되는 것이다.
- 서버에서 제대로 동작함을 확인한다.
하마드