![[SpringMVC] MVC 프레임워크 만들기](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbT1bLX%2Fbtq3oSLbBtR%2F2btLifeB0cwfcWFqcLhLzK%2Fimg.png)
스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의
웹 애플리케이션을 개발할 때 필요한 모든 웹 기술을 기초부터 이해하고, 완성할 수 있습니다. 스프링 MVC의 핵심 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니다., 원
www.inflearn.com
강의를 들으며 생각 정리
앞서 MVC 패턴의 한계들을 살펴보고 프론트 컨트롤러의 필요성에 대해 알아봤다.
이러한 프론트 컨트롤러가 핵심이 되는 MVC 프레임워크를 최대한 기존 구조를 유지하면서 단계적으로 만들면서 궁극적으로 스프링 MVC와 유사한 구조로 발전시키는 것이 이번 공부의 목적이다.
단계적으로 만듦으로써 스프링 MVC가 어떤 이유로 어떻게 만들어졌는지를 자연스럽게 이해할 수 있을 것이다.
프론트 컨트롤러 패턴 소개
기존에 만들었던 MVC 패턴은 다음과 같은 구조로 되어 있다.
클라이언트1 -----호출-----> 공통, A로직(컨트롤러A)
클라이언트2 -----호출-----> 공통, B로직(컨트롤러B)
클라이언트3 -----호출-----> 공통, C로직(컨트롤러C)
-> 이처럼 모든 컨트롤러가 각자의 로직 뿐만 아니라 공통 로직을 포함하고 있다.
<프론트 컨트롤러 도입 후>
클라이언트1 -----호출-----> ---> A로직(컨트롤러A)
클라이언트2 -----호출-----> 공통(프론트 컨트롤러) ---> B로직(컨트롤러B)
클라이언트3 -----호출-----> ----> C로직(컨트롤러C)
-> 프론트 컨트롤러의 공통 로직을 먼저 수행하고 후에 요청한 컨트롤러로 이동한다.
<프론트 컨트롤러 패턴 특징>
- 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음 -> 입구를 하나로 만든다.
- 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출
- 공통 처리 가능
- 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨 -> 서블릿이 애초에 URL을 받아서 로직을 수행하는 역할을 하기 때문에 프론트 컨트롤러에서 한 번 처리하면 또 URL 처리를 할 필요가 없다.
<스프링 웹 MVC와 프론트 컨트롤러>
스프링 웹 MVC의 핵심도 바로 프론트 컨트롤러이다.
스프링 웹 MVC의 DispatcherServlet이 프론트 컨트롤러 패턴으로 구현되어 있다.
이제 단계적으로 MVC 프레임워크를 구현해보자.
프론트 컨트롤러 도입 - v1
먼저 프론트 컨트롤러를 도입해보자. 이번 목표는 기존 코드를 최대한 유지하면서, 프론트 컨트롤러를 도입하는 것이다. 먼저 구조를 맞추어두고 점진적으로 리펙토링 해보자.
v1 단계에서는 클라이언트의 HTTP 요청 URL에 따라 프론트 컨트롤러에서 매핑 정보(URL -> Controller)를 분석해 알맞은 컨트롤러를 호출하는 것을 목표로 한다. 나머지 컨트롤러->JSP->응답의 과정은 기존과 동일하다.
<컨트롤러>
먼저 여러 컨트롤러들을 의존하는 하나의 컨트롤러 인터페이스를 만들 것이다. 인터페이스를 만드는 이유는 프론트 컨트롤러 입장에서 인터페이스만 의존하고 매핑 정보에 따라서 구현체 컨트롤러를 호출하기 위해서다. 코드를 보면 쉽게 이해할 수 있을 것이다.
<ControllerV1>
public interface ControllerV1 {
void process(HttpServletRequest request, HttpServletResponse response) throws ServletException,IOException;
}서블릿과 비슷한 모양의 컨트롤러 인터페이스다. 각 컨트롤러들은 이 인터페이스를 구현하면 된다. 프론트 컨트롤러는 이 인터페이스를 호출해서 구현과 관계없이 로직의 일관성을 가져갈 수 있다.(다형성)
이제 이 인터페이스를 구현한 컨트롤러를 만들어보자. 기존 로직은 최대한 유지하는 것이 핵심이다.
<MemberFormControllerV1 - 회원 등록 컨트롤러>
public class MemberFormControllerV1 implements ControllerV1 {
@Override
public void process(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String viewPath = "/WEB-INF/views/new-form.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request,response);
}
}<MemberSaveControllerV1 - 회원 저장 컨트롤러>
public class MemberSaveControllerV1 implements ControllerV1 {
private MemberRepository memberRepository = MemberRepository.getInstance();
@Override
public void process(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");
int age = Integer.parseInt(request.getParameter("age"));
Member member = new Member(username, age);
memberRepository.save(member);
//Model에 데이터를 보관한다.
request.setAttribute("member", member);
String viewPath = "/WEB-INF/views/save-result.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);
}
}<MemberListControllerV1 - 회원 목록 컨트롤러>
public class MemberListControllerV1 implements ControllerV1 {
private MemberRepository memberRepository = MemberRepository.getInstance();
@Override
public void process(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
List<Member> members = memberRepository.findAll();
request.setAttribute("members", members);
String viewPath = "/WEB-INF/views/members.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);
}
}내부 로직은 기존 서블릿과 같다. 그러나 실제 서블릿은 아니고 인터페이스를 구현한 클래스이다. 이제 프론트 컨트롤러를 만들어보자.
<FrontControllerServletV1 - 프론트 컨트롤러>
@WebServlet(name = "frontControllerServletV1", urlPatterns = "/front-controller/v1/*")
public class FrontControllerServletV1 extends HttpServlet {
private Map<String, ControllerV1> controllerMap = new HashMap<>();
public FrontControllerServletV1() {
controllerMap.put("/front-controller/v1/members/new-form", new MemberFormControllerV1());
controllerMap.put("/front-controller/v1/members/save", new MemberSaveControllerV1());
controllerMap.put("/front-controller/v1/members", new MemberListControllerV1());
}
@Override
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String requestURI = request.getRequestURI();
ControllerV1 controller = controllerMap.get(requestURI);
if (controller == null) {
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
controller.process(request, response);
}
}<프론트 컨트롤러 분석>
- urlPatterns
urlPatterns = "/front-controller/v1/*" : /front-controller/v1를 포함한 하위 모든 요청은 이 서블릿에서 받아들인다.
- controllerMap
key : 매핑 URL
value : 호출될 컨트롤러
-> 매핑 정보에 해당한다.
- 생성자
서블릿이 생성될 때, controllerMap을 이용해 각 URL들을 기존에 만든 구체 컨트롤러들과 매핑시킨다.
- service()
먼저 requestURI를 조회해서 실제 호출한 컨트롤러를 controllerMap에서 찾는다. 만약 없다면 404 상태 코드를 반환한다.
컨트롤러를 찾고 controller.process(request, response)를 호출해서 해당 컨트롤러를 실행한다.
- JSP
JSP는 이전 MVC에서 사용했던 것을 그대로 사용한다.
-> 기존 서블릿, JSP로 만든 MVC와 동일하게 실행되는 것을 확인할 수 있다.
<회원 폼>
<회원 등록>
+) 기존에 폼을 상대경로(save)로 설정했기 때문에 기존 JSP를 사용할 수 있는 것이다.(URL 참고)
<회원 목록>
+) 프론트 컨트롤러를 도입한 단계가 더 복잡하다고 느낄 수 있다. 이제부터 이를 어떻게 바꿔 나가는지 볼 것이다.
String viewPath = "/WEB-INF/views/members.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);그리고 아직 위 코드처럼 중복되는 코드와 같은 부분들은 해결되지 않았고 이 역시 점차 해결해 나갈 것이다.
-> 어떤 개발된 애플리케이션을 수정할 때 구조적인 것과 세부적인 것을 수정해야 한다면 더 큰 계층인 구조적인 것에 집중하고 세부적인 부분은 일단 냅두는 것이 좋다. 한 번에 모든 것을 수정하려고 하면 너무 복잡해져서 오히려 생각하기 힘들어질 것이다. 지금은 일단 프론트 컨트롤러를 도입하는 구조적인 것을 수정하는 과정이고 코드 중복 등의 세부적인 계층에 대해서는 이후 과정에서 점진적으로 수정하자.
View 분리 - v2
모든 컨트롤러에서 뷰로 이동하는 부분에 중복이 있고, 깔끔하지 않다.
String viewPath = "/WEB-INF/views/new-form.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);이 부분을 깔끔하게 분리하기 위해 별도로 뷰를 처리하는 객체를 만들자.
v1에서는 컨트롤러가 뷰(JSP)를 직접 호출했다.
v2에서는 모든 컨트롤러에서 중복되는 뷰 호출 부분도 프론트 컨트롤러에서 담당한다. 각각의 컨트롤러는 프론트 컨트롤러에게 View의 정보를 반환하기만 하면 된다.
더 복잡해질 것이라 생각할 수 있는데 코드를 보면 더 깔끔한 로직을 볼 수 있을 것이다.
우선 뷰 전용 객체를 하나 만든다.
<MyView>
public class MyView {
private String viewPath;
public MyView(String viewPath) {
this.viewPath = viewPath;
}
public void render(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);
}
}앞서 중복되는 JSP를 포워드 하는 부분은 이제부터 MyView 객체에서 담당한다. 이제 다음 버전의 컨트롤러 인터페이스를 만들어보자.
<ControllerV2>
public interface ControllerV2 {
MyView process(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException;
}이 때 컨트롤러가 뷰를 반환하는 특징이 있다. 이제 구체 컨트롤러들을 만들어보자.
<MemberFormControllerV2>
public class MemberFormControllerV2 implements ControllerV2 {
@Override
public MyView process(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
return new MyView("/WEB-INF/views/new-form.jsp");
}
}이제 각 컨트롤러는 복잡한 dispatcher.forward()를 직접 생성해서 호출하지 않아도 된다. 단순히 MyView 객체를 생성하고 거기에 뷰의 경로만 넣고 반환하면 된다.
<MemberSaveControllerV2>
public class MemberSaveControllerV2 implements ControllerV2 {
private MemberRepository memberRepository = MemberRepository.getInstance();
@Override
public MyView process(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");
int age = Integer.parseInt(request.getParameter("age"));
Member member = new Member(username, age);
memberRepository.save(member);
//Model에 데이터를 보관한다.
request.setAttribute("member", member);
return new MyView("/WEB-INF/views/save-result.jsp");
}
}
<MemberListControllerV2>
public class MemberListControllerV2 implements ControllerV2 {
private MemberRepository memberRepository = MemberRepository.getInstance();
@Override
public MyView process(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
List<Member> members = memberRepository.findAll();
request.setAttribute("members", members);
return new MyView("/WEB-INF/views/members.jsp");
}
}
이제 프론트 컨트롤러를 만든다. 프론트 컨트롤러를 보면 어떤 식으로 로직이 구성되는지 감이 올 것이다.
<FrontControllerServletV2>
@WebServlet(name = "frontControllerServletV2", urlPatterns = "/front-controller/v2/*")
public class FrontControllerServletV2 extends HttpServlet {
private Map<String, ControllerV2> controllerMap = new HashMap<>();
public FrontControllerServletV2() {
controllerMap.put("/front-controller/v2/members/new-form", new MemberFormControllerV2());
controllerMap.put("/front-controller/v2/members/save", new MemberSaveControllerV2());
controllerMap.put("/front-controller/v2/members", new MemberListControllerV2());
}
@Override
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String requestURI = request.getRequestURI();
ControllerV2 controller = controllerMap.get(requestURI);
if (controller == null) {
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
MyView view = controller.process(request, response);
view.render(request, response);
}
}기본적으로 v1의 프론트 컨트롤러 구조를 띄고 있다. 그런데 controller.process(request, response)에서 MyView를 반환 받고 view.render()를 호출하는 로직을 추가했다. view.render()를 호출하면 MyView에서 forward 로직을 수행해서 JSP가 실행된다.
+) 결과(폼, 회원 가입, 회원 목록) 화면은 항상 같기 때문에 앞으로 생략하겠다.
프론트 컨트롤러의 도입으로 MyView 객체의 render()를 호출하는 부분을 모두 일관되게 처리할 수 있다. 각각의 컨트롤러는 비즈니스 로직 수행 후 MyView 객체를 생성만 해서 반환하면 된다.
v2에서는 v1에서 MyView를 추가함으로써 구조를 변경했다. 지금까지는 request를 모델로써 사용했는데 이제 모델의 개념을 도입하고 response와 같은 필요 없는데 스펙상 받고 있는 부분들을 개선해보자.
Model 추가 - v3
지금까지 만든 구조에서 다음과 같은 사항들을 개선하고 싶다.
<서블릿 종속성 제거>
컨트롤러 입장에서 request, response가 꼭 필요할까?
<MemberSaveControllerV2 - 일부>
String username = request.getParameter("username");
int age = Integer.parseInt(request.getParameter("age"));response는 필요 없어도 회원 저장 컨트롤러에서는 위와 같이 파라미터 정보를 위해 request가 필요하다. 그러나 요청 파라미터 정보를 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 request, response 모두를, 즉, 서블릿 기술을 몰라도 동작할 수 있다.
그리고 request 객체를 모델로 사용하는 대신에 별도의 모델 객체를 만들어서 반환하면 된다.
-> 우리가 구현하는 컨트롤러가 서블릿 기술을 전혀 사용하지 않도록 변경해보자. 이렇게 하면 구현 코드도 매우 단순해진다.
<뷰 이름 중복 제거>
컨트롤러에서 지정하는 뷰 이름에 중복이 있는 것을 확인할 수 있다.
컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화하자. 이렇게 해두면 향후 뷰의 폴더 위치가 바뀌더라도 프론트 컨트롤러만 고치면 된다.
-> 이처럼 수정사항이 있을 때 여러 곳에서 수정하지 않고 한 곳에서만 수정하는 개발 방식이 좋다.
/WEB-INF/views/new-form.jsp -> new-form
/WEB-INF/views/save-result.jsp -> save-result
/WEB-INF/views/members.jsp -> members
<v2에서 변경된 점>
1. 컨트롤러가 MyView(뷰)가 아닌 ModelView(모델+뷰)를 프론트 컨트롤러에 반환한다.
2. 뷰의 논리 이름을 viewResolver에게 보내 뷰의 실제 물리 경로를 갖는 MyView 객체를 반환한다.
3. request를 모델로서 사용하지 않기 때문에 프론트 컨트롤러에서 render시에 model을 같이 보낸다.
-> v3에서 변화가 가장 크다. 집중해서 정확히 이해하고 v4로 넘어가자.
<ModelView>
지금까지 컨트롤러에서 서블릿에 종속적인 request를 사용했다. 그리고 모델도 request를 통해 데이터를 저장하고 뷰에 전달했다.
서블릿의 종속성을 제거하기 위해 모델을 직접 만들고, 추가로 뷰의 이름까지 전달하는 객체를 만들어보자.
@Getter @Setter
public class ModelView {
private String viewName;
private Map<String, Object> model = new HashMap<>();
public ModelView(String viewName) {
this.viewName = viewName;
}
}기본적으로 모델 정보를 갖고 있는 객체인데 여기에 뷰의 논리 이름을 추가로 갖고 있다 생각하면 된다.
모델은 map으로 되어 있고 컨트롤러에서 뷰에 필요한 데이터를 모델에 key, value로 넣어주면 된다.
<ControllerV3>
public interface ControllerV3 {
ModelView process(Map<String, String> paramMap);
}v3의 컨트롤러 인터페이스다. 이 컨트롤러는 서블릿 기술을 전혀 사용하지 않는다. 따라서 구현이 매우 단순해졌다.
- 입력 : request에서 파라미터를 직접 추출할 때와 달리 프론트 컨트롤러에서 미리 paramMap에 파라미터 정보를 넣어서 컨트롤러를 호출해준다.
- 출력 : 응답 결과로 뷰 논리 이름과 뷰에 전달한 모델 데이터를 포함하는 ModelView 객체를 반환한다.
<MemberFormControllerV3 - 회원 등록 폼>
public class MemberFormControllerV3 implements ControllerV3 {
@Override
public ModelView process(Map<String, String> paramMap) {
return new ModelView("new-form");
}
}ModelView를 생성할 때 new-form이라는 view의 논리적인 이름을 지정한다. 실제 물리적인 이름은 프론트 컨트롤러에서 처리한다.
<MemberSaveControllerV3 - 회원 저장>
public class MemberSaveControllerV3 implements ControllerV3 {
private MemberRepository memberRepository = MemberRepository.getInstance();
@Override
public ModelView process(Map<String, String> paramMap) {
String username = paramMap.get("username");
int age = Integer.parseInt(paramMap.get("age"));
Member member = new Member(username, age);
memberRepository.save(member);
ModelView mv = new ModelView("save-result");
mv.getModel().put("member", member);
return mv;
}
}- paramMap.get()
파라미터 정보가 이미 paramMap에 담겨있다. map에서 필요한 요청 파라미터를 조회하면 된다.
- mv.getModel().put()
모델은 단순한 map이므로 모델에 뷰에서 필요한 Member 객체를 담고 반환한다.
<MemberListControllerV3 - 회원 목록>
public class MemberListControllerV3 implements ControllerV3 {
private MemberRepository memberRepository = MemberRepository.getInstance();
@Override
public ModelView process(Map<String, String> paramMap) {
List<Member> members = memberRepository.findAll();
ModelView mv = new ModelView("members");
mv.getModel().put("members", members);
return mv;
}
}
<FrontControllerSevletV3>
@WebServlet(name = "frontControllerServletV3", urlPatterns = "/front-controller/v3/*")
public class FrontControllerServletV3 extends HttpServlet {
private Map<String, ControllerV3> controllerMap = new HashMap<>();
public FrontControllerServletV3() {
controllerMap.put("/front-controller/v3/members/new-form", new MemberFormControllerV3());
controllerMap.put("/front-controller/v3/members/save", new MemberSaveControllerV3());
controllerMap.put("/front-controller/v3/members", new MemberListControllerV3());
}
@Override
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String requestURI = request.getRequestURI();
ControllerV3 controller = controllerMap.get(requestURI);
if (controller == null) {
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
Map<String, String> paramMap = createParamMap(request);
ModelView mv = controller.process(paramMap);
String viewName = mv.getViewName();
MyView view = viewResolver(viewName);
view.render(mv.getModel(), request, response);
}
private MyView viewResolver(String viewName) {
return new MyView("/WEB-INF/views/" + viewName + ".jsp");
}
private Map<String, String> createParamMap(HttpServletRequest request) {
Map<String, String> paramMap = new HashMap<>();
request.getParameterNames().asIterator()
.forEachRemaining(paramName -> paramMap.put(paramName, request.getParameter(paramName)));
return paramMap;
}
}프론트 컨트롤러가 점점 복잡해진다. 일단 컨트롤러 객체를 받는 구간인 controllerMap.get()까지는 동일하다. v2와의 차이점을 차근차근 분석해보자.
- createParamMap()
v3는 파라미터 정보를 request가 아닌 paramMap으로 사용함으로써 컨트롤러의 서블릿 종속성을 피할 수 있다고 했다. 그래서 request 정보를 기반으로 paramMap을 만드는 메서드를 추가했다.
- controller.process(paramMap)
paramMap을 컨트롤러에 전달하면서 호출한다. 컨트롤러 안에서 비즈니스 로직을 수행하고 뷰에 전달할 모델과 뷰의 논리 이름을 담고 있는 ModelView 객체를 반환한다.
- viewResolver()
컨트롤러가 반환한 뷰의 논리 이름을 실제 물리 경로로 변경한다. 그리고 실제 물리 경로가 있는 MyView 객체를 반환한다.
- render(mv.getModel(), request, response)
v3의 MyView 객체의 render()는 모델 정보도 함께 받는다. 이 메서드 역시 MyView 객체에서 오버로딩하자.
<MyView>
public class MyView {
private String viewPath;
public MyView(String viewPath) {
this.viewPath = viewPath;
}
public void render(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);
}
public void render(Map<String, Object> model, HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
modelToRequestAttribute(model, request);
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);
}
private void modelToRequestAttribute(Map<String, Object> model, HttpServletRequest request) {
model.forEach((key, value) -> request.setAttribute(key, value));
}
}JSP는 request.getAttribute()로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서 request.setAttribute()로 담아둔다. 이후 JSP로 포워드해서 JSP를 렌더링 한다.
-> 프론트 컨트롤러에서 request->paramMap, MyView에서 paramMap->request를 수행한다.
+) 이번 코드를 보면 로직을 메서드화 시킨 부분들이 많다. 이처럼 세부적인 로직이나 어떤 로직인지 한 번에 알기 어려운 부분들은 의미 있는 이름의 메서드로 변경하는 것이 코드가 깔끔해지고 좋다.
단순하고 실용적인 컨트롤러 - v4
앞서 만든 v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하는 등, 잘 설계된 컨트롤러이다. 그런데 실제 컨트롤러 인터페이스를 구현하는 개발자 입장에서 보면, 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 조금은 번거롭다.
좋은 프레임워크는 아키텍처도 중요하지만, 그와 더불어 실제 개발하는 개발자가 단순하고 편리하게 사용할 수 있어야 한다. 소위 실용성이 있어야 한다.
+) 스프링은 기능 자체가 워낙 많지만 아키텍처, 실용성 둘 다 잡았기 때문에 성공할 수 있었다.
이번에는 v3를 조금 변경해서 실제 구현하는 개발자들이 매우 편리하게 개발할 수 있는 v4 버전을 개발해보자.
v3와 차이점
- 기존 v3는 컨트롤러에서 ModelView 객체를 반환했다.
- v4는 오로지 ViewName만 반환한다. -> 모델은 프론트 컨트롤러에서 컨트롤러를 호출할 때 인자로 사용한다.
<ControllerV4>
public interface ControllerV4 {
/**
*
* @param paramMap
* @param model
* @return viewName
*/
String process(Map<String, String> paramMap, Map<String, Object> model);
}모델은 파라미터로 전달되기 때문에 ModelView가 아닌 뷰의 이름만 반환해주면 된다.
<MemberFormControllerV4>
public class MemberFormControllerV4 implements ControllerV4 {
@Override
public String process(Map<String, String> paramMap, Map<String, Object> model) {
return "new-form";
}
}정말 단순하게 new-form이라는 뷰의 논리 이름만 반환하면 된다.
<MemberSaveControllerV4>
public class MemberSaveControllerV4 implements ControllerV4 {
private MemberRepository memberRepository = MemberRepository.getInstance();
@Override
public String process(Map<String, String> paramMap, Map<String, Object> model) {
String username = paramMap.get("username");
int age = Integer.parseInt(paramMap.get("age"));
Member member = new Member(username, age);
memberRepository.save(member);
model.put("member", member);
return "save-result";
}
}이전에는 ModelView 객체를 만들었었는데 이제는 파라미터로 전달된 model에 데이터를 집어넣고 뷰의 논리 이름만을 반환한다.
<MemberListControllerV4>
public class MemberListControllerV4 implements ControllerV4 {
private MemberRepository memberRepository = MemberRepository.getInstance();
@Override
public String process(Map<String, String> paramMap, Map<String, Object> model) {
List<Member> members = memberRepository.findAll();
model.put("members", members);
return "members";
}
}
<FrontControllerServletV4>
@WebServlet(name = "frontControllerServletV4", urlPatterns = "/front-controller/v4/*")
public class FrontControllerServletV4 extends HttpServlet {
private Map<String, ControllerV4> controllerMap = new HashMap<>();
public FrontControllerServletV4() {
controllerMap.put("/front-controller/v4/members/new-form", new MemberFormControllerV4());
controllerMap.put("/front-controller/v4/members/save", new MemberSaveControllerV4());
controllerMap.put("/front-controller/v4/members", new MemberListControllerV4());
}
@Override
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String requestURI = request.getRequestURI();
ControllerV4 controller = controllerMap.get(requestURI);
if (controller == null) {
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
Map<String, String> paramMap = createParamMap(request);
Map<String, Object> model = new HashMap<>(); //추가
String viewName = controller.process(paramMap, model);
MyView view = viewResolver(viewName);
view.render(model, request, response);
}
private MyView viewResolver(String viewName) {
return new MyView("/WEB-INF/views/" + viewName + ".jsp");
}
private Map<String, String> createParamMap(HttpServletRequest request) {
Map<String, String> paramMap = new HashMap<>();
request.getParameterNames().asIterator()
.forEachRemaining(paramName -> paramMap.put(paramName, request.getParameter(paramName)));
return paramMap;
}
}이전 버전과 거의 동일하다.
추가된 부분은 모델 객체를 직접 생성해서 컨트롤러에게 파라미터로 넘겨준다는 것이다.
이번 버전의 컨트롤러는 매우 단순하고 실용적이다. 기존 구조에서 모델을 파라미터로 넘기고, 뷰의 논리 이름을 반환한다는 작은 아이디어를 적용했을 뿐인데, 컨트롤러를 구현하는 개발자 입장에서 보면 이제 군더더기 없는 코드를 작성할 수 있다.
또한 중요한 사실은 여기까지 한 번에 온 것이 아니라는 점이다. 프레임워크가 점진적으로 발전하는 과정 속에서 이런 방법도 찾을 수 있는 것이다.
-> 프레임워크나 공통 기능이 수고로워야 사용하는 개발자가 편리해진다.
유연한 컨트롤러1 - v5
지금까지 매우 실용적인 MVC 프레임워크를 단계적으로 개발했다.
그런데 만약 어떤 개발자는 v3 방식으로 개발하고 싶고, 어떤 개발자는 v4 방식으로 개발하고 싶다면 어떻게 해야할까?
public interface ControllerV3 {
ModelView process(Map<String, String> paramMap);
}public interface ControllerV4 {
String process(Map<String, String> paramMap, Map<String, Object> model);
}
<어댑터 패턴>
지금까지 우리가 개발한 프론트 컨트롤러는 한 가지 방식의 컨트롤러 인터페이스만 사용할 수 있다.
ex) private Map<String, ControllerV4> controllerMap = new HashMap<>(); (매핑 정보)
그러나 ControllerV3, ControllerV4는 완전히 다른 인터페이스이다. 마치 v3는 100v, v4는 220v 전기 콘센트 같은 것이다. 이럴 때 사용하는 것이 바로 어댑터이다.
어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해보자.
V5 구조
구조가 상당히 변화했지만 메커니즘은 비슷하다.
- 핸들러 : 어댑터가 있기 때문에 이제부터 컨트롤러의 이름을 더 넓은 범위인 핸들러로 부르겠다.
- 핸들러 어댑터 : 프론트 컨트롤러가 바로 핸들러를 호출하는 것이 아닌 중간에 어댑터를 거쳐서 핸들러를 호출한다. 이는 확장성을 위해서이다.
- 핸들러 매핑 정보 : 기존 컨트롤러 매핑 정보는 한 가지 방식의 컨트롤러 인터페이스만 사용가능했다면 이제 모든 방식의 컨트롤러 인터페이스 매핑 정보를 담고 있다.
- 컨트롤러 어댑터 목록 : V3, V4 등의 핸들러를 처리할 수 있는 어댑터 리스트이다.
<MyHandlerAdapter>
어댑터는 이렇게 구현해야 한다는 어댑터용 인터페이스이다.
기존 ControllerV3, ControllerV4의 더 상위 계층이라 보면 된다.
public interface MyHandlerAdapter {
boolean supports(Object handler);
ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws ServletException, IOException;
}- supports : 어댑터가 해당 handler(컨트롤러)를 처리할 수 있는지 판단하는 메서드다.
- handle : 어댑터는 실제 컨트롤러를 호출하고, 그 결과로 ModelView를 반환한다. 이전에는 프론트 컨트롤러가 실제 컨트롤러를 호출했지만(controller.process()), 이제는 이 어댑터를 통해서 실제 컨트롤러가 호출된다.
이제 실제 어댑터를 구현해보자. 이번 장에서는 ControllerV3를 지원하는 어댑터를 구현하겠다.
<ControllerV3HandlerAdapter>
public class ControllerV3HandlerAdapter implements MyHandlerAdapter {
@Override
public boolean supports(Object handler) {
return (handler instanceof ControllerV3);
}
@Override
public ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws ServletException, IOException {
ControllerV3 controller = (ControllerV3) handler;
Map<String, String> paramMap = createParamMap(request);
ModelView mv = controller.process(paramMap);
return mv;
}
private Map<String, String> createParamMap(HttpServletRequest request) {
Map<String, String> paramMap = new HashMap<>();
request.getParameterNames().asIterator()
.forEachRemaining(paramName -> paramMap.put(paramName, request.getParameter(paramName)));
return paramMap;
}
}- supports : ControllerV3를 처리할 수 있는 어댑터를 뜻한다.
- handle : 핸들러를 컨트롤러 V3로 변환한 다음에 V3 형식에 맞도록 호출한다. supports를 통해 ControllerV3만 지원하기 때문에 타입 변환은 걱정없이 실행해도 된다.
<FrontControllerServletV5>
@WebServlet(name = "frontControllerServletV5", urlPatterns = "/front-controller/v5/*")
public class FrontControllerServletV5 extends HttpServlet {
private final Map<String, Object> handlerMappingMap = new HashMap<>();
private final List<MyHandlerAdapter> handlerAdapters = new ArrayList<>();
public FrontControllerServletV5() {
initHandlerMappingMap();
initHandlerAdapters();
}
private void initHandlerMappingMap() {
handlerMappingMap.put("/front-controller/v5/v3/members/new-form", new MemberFormControllerV3());
handlerMappingMap.put("/front-controller/v5/v3/members/save", new MemberSaveControllerV3());
handlerMappingMap.put("/front-controller/v5/v3/members", new MemberListControllerV3());
}
private void initHandlerAdapters() {
handlerAdapters.add(new ControllerV3HandlerAdapter());
}
@Override
public void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
Object handler = getHandler(request);
if (handler == null) {
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
return;
}
MyHandlerAdapter adapter = getHandlerAdapter(handler);
ModelView mv = adapter.handle(request, response, handler);
String viewName = mv.getViewName();
MyView view = viewResolver(viewName);
view.render(mv.getModel(), request, response);
}
private Object getHandler(HttpServletRequest request) {
String requestURI = request.getRequestURI();
return handlerMappingMap.get(requestURI);
}
private MyHandlerAdapter getHandlerAdapter(Object handler) {
for (MyHandlerAdapter adapter : handlerAdapters) {
if (adapter.supports(handler)) {
return adapter;
}
}
throw new IllegalArgumentException("handler adapter를 찾을 수 없습니다. handler=" + handler);
}
private MyView viewResolver(String viewName) {
return new MyView("/WEB-INF/views/" + viewName + ".jsp");
}
}v5의 프론트 컨트롤러다. 하나하나 분석해보자.
- 생성자
initHandlerMappingMap(); //기존 controllerMap처럼 핸들러 매핑을 초기화한다.
initHandlerAdapters(); //어댑터 리스트에 어댑터를 추가한다.
- 매핑 정보
private final Map handlerMappingMap = new HashMap<>();
매핑 정보의 값이 ControllerV3 , ControllerV4 같은 인터페이스에서 아무 값이나 받을 수 있는 Object 로 변경되었다.
- 핸들러 매핑
Object handler = getHandler(request)
핸들러 매핑 정보인 handlerMappingMap에서 URL에 매핑된 핸들러 객체를 찾아서 반환한다.
- 핸들러를 처리할 수 있는 어댑터 조회
MyHandlerAdapter adapter = getHandlerAdapter(handler)
핸들러를 처리할 수 있는 어댑터를 supports 메서드를 통해서 찾는다.
- 어댑터 호출
ModelView mv = adapter.handle(request, response, handler);
어댑터의 handle 매서드를 통해 실제 어댑터가 호출된다.
지금은 V3 컨트롤러를 사용할 수 있는 어댑터와 ControllerV3만 들어 있어서 크게 감흥이 없을 것이다. 이제 ControllerV4를 사용할 수 있도록 기능을 추가해보자.
유연한 컨트롤러2 - v5
프론트 컨트롤러에 ControllerV4 기능을 추가한다.
<FrontControllerServletV5 - 일부>
private void initHandlerMappingMap() {
handlerMappingMap.put("/front-controller/v5/v3/members/new-form", new MemberFormControllerV3());
handlerMappingMap.put("/front-controller/v5/v3/members/save", new MemberSaveControllerV3());
handlerMappingMap.put("/front-controller/v5/v3/members", new MemberListControllerV3());
//V4 추가
handlerMappingMap.put("/front-controller/v5/v4/members/new-form", new MemberFormControllerV4());
handlerMappingMap.put("/front-controller/v5/v4/members/save", new MemberSaveControllerV4());
handlerMappingMap.put("/front-controller/v5/v4/members", new MemberListControllerV4());
}
private void initHandlerAdapters() {
handlerAdapters.add(new ControllerV3HandlerAdapter());
handlerAdapters.add(new ControllerV4HandlerAdapter());
}
v4의 컨트롤러들을 처리할 수 있는 어댑터를 추가한다.
<ControllerV4HandlerAdapter>
public class ControllerV4HandlerAdapter implements MyHandlerAdapter {
@Override
public boolean supports(Object handler) {
return (handler instanceof ControllerV4);
}
@Override
public ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws ServletException, IOException {
ControllerV4 controller = (ControllerV4) handler;
Map<String, String> paramMap = createParamMap(request);
HashMap<String, Object> model = new HashMap<>();
String viewName = controller.process(paramMap, model);
ModelView mv = new ModelView(viewName);
mv.setModel(model);
return mv;
}
private Map<String, String> createParamMap(HttpServletRequest request) {
Map<String, String> paramMap = new HashMap<>();
request.getParameterNames().asIterator()
.forEachRemaining(paramName -> paramMap.put(paramName, request.getParameter(paramName)));
return paramMap;
}
}- supports : 기존 v3의 경우와 동일한 로직이다.
- handle : v3와 다르게 v4는 컨트롤러의 인자로 paramMap과 모델을 사용하기 때문에 모델을 생성하고 인자로 보내준다.
- 어댑터가 호출하는 ControllerV4는 뷰의 이름을 반환한다. 그런데 어댑터는 뷰의 이름이 아니라 ModelView를 만들어서 반환해야 한다. 어댑터는 이것을 ModelView로 만들어서 형식을 맞추어 반환한다. 이것이 어댑터가 꼭 필요한 이유이다.
-> 이렇게 어댑터 하나만 추가해주는 정도로 메인 로직은 유지한 채 확장을 매우 쉽게 할 수 있다.
정리
지금까지 v1 ~ v5로 점진적으로 프레임워크를 발전시켜 왔다. 지금까지 한 작업을 정리해보자.
<v1: 프론트 컨트롤러를 도입>
기존 구조를 최대한 유지하면서 프론트 컨트롤러를 도입
<v2: View 분류>
단순 반복되는 뷰 로직 분리
<v3: Model 추가>
서블릿 종속성 제거
뷰 이름 중복 제거
<v4: 단순하고 실용적인 컨트롤러>
v3와 거의 비슷
구현 입장에서 ModelView를 직접 생성해서 반환하지 않도록 편리한 인터페이스 제공
<v5: 유연한 컨트롤러>
어댑터 도입
어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계
+) 다형성
지금까지 만든 프레임워크를 보면 다형성과 어댑터 덕분에 기존 구조를 유지하면서, 프레임워크의 기능을 확장할 수 있다. 물론 단순한 것은 if ~ else 구문으로 대신해도 되겠지만 향후 확장성을 고려한다면 다형성 스타일로 코드를 바꾸는게 좋다. 이번에 다형성을 사용함으로써 어떤 효과가 있었는지 충분히 훈련이 되었을 것이다.
-> 특히 스프링에서는 역할과 구현을 구분하는 다형성이 매우 잘 지켜져 있다.
+) 스프링 MVC
지금까지 스프링 MVC의 핵심 구조를 파악하는데 필요한 부분은 모두 만들어보았다. 사실 지금까지 작성한 코드는 스프링 MVC 프레임워크의 핵심 코드의 축약 버전이고 구조도 거의 같다.
이제 웹 애플리케이션이 스프링 MVC 프레임워크 구조로 어떤 과정을 거쳐 발전해 왔는지 이해했으니 본격적으로 스프링 MVC에 대해서 공부해보자.
'java > spring' 카테고리의 다른 글
| [Spring] 로깅 (0) | 2021.05.10 |
|---|---|
| [SpringMVC] 스프링 MVC - 구조 이해 (0) | 2021.04.26 |
| [SpringMVC] 서블릿, JSP, MVC 패턴 (0) | 2021.04.23 |
| [SpringMVC] 서블릿 (0) | 2021.04.21 |
| [SpringMVC] 웹 애플리케이션 이해 (0) | 2021.04.21 |