Model 추가 - v3, 단순하고 실용적인 v4

Model 추가 - v3

서블릿 종속성 제거

컨트롤러 입장에서 HttpServletRequest, HttpServletResponse이 꼭 필요할까? 요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다. 그리고 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다. 우리가 구현하는 컨트롤러가 서블릿 기술을 전혀 사용하지 않도록 변경해보자. 이렇게 하면 구현 코드도 매우 단순해지고, 테스트 코드 작성이 쉽다.

 

뷰 이름 중복 제거

컨트롤러에서 지정하는 뷰 이름에 중복이 있는 것을 확인할 수 있다. 컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화 하자.

이렇게 해두면 향후 뷰의 폴더 위치가 함께 이동해도 프론트 컨트롤러만 고치면 된다.

• /WEB-INF/views/new-form.jsp new-form -> new-form
• /WEB-INF/views/save-result.jsp save-result -> save-result
• /WEB-INF/views/members.jsp members -> members

ModelView
뷰의 이름과 뷰를 렌더링 할 때 필요한 model 객체를 가지고 있다. model은 단순히 map으로 되어 있으므로 컨트롤러에서 뷰에 필요한 데이터를 key, value로 넣어주면 된다.

 

ControllerV3

이 컨트롤러는 서블릿 기술을 전혀 사용하지 않는다. 따라서 구현이 매우 단순해지고, 테스트 코드 작성 시 테스트하기 쉽다. HttpServletRequest가 제공하는 파라미터는 프론트 컨트롤러가 paramMap에 담아서 호출해주면 된다. 응답 결과로 뷰 이름과 뷰에 전달할 Model 데이터를 포함하는 ModelView 객체를 반환하면 된다.

 

MemberFormControllerV3 - 회원 등록 폼

ModelView를 생성할 때 new-form이라는 view의 논리적인 이름을 지정한다. 실제 물리적인 이름은 프론트 컨트롤러에서 처리한다.

 

MemberSaveControllerV3 - 회원 저장

paramMap.get("username");

파라미터 정보는 map에 담겨있다. map에서 필요한 요청 파라미터를 조회하면 된다.

mv.getModel().put("member", member);

모델은 단순한 map이므로 모델에 뷰에서 필요한 member 객체를 담고 반환한다.

 

MemberListControllerV3 - 회원 목록

 

FrontControllerServletV3

createParamMap()

HttpServletRequest에서 파라미터 정보를 꺼내서 Map으로 변환한다. 그리고 해당 Map( paramMap )을 컨트롤러에 전달하면서 호출한다.

 

뷰 리졸버

MyView view = viewResolver(viewName) 컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 경로로 변경한다. 그리고 실제 물리 경로가 있는 MyView 객체를 반환한다.

• 논리 뷰 이름: members
• 물리 뷰 경로: /WEB-INF/views/members.jsp

 

view.render(mv.getModel(), request, response)

• 뷰 객체를 통해서 HTML 화면을 렌더링 한다.
• 뷰 객체의 render()는 모델 정보도 함께 받는다.
• JSP는 request.getAttribute() 로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서 request.setAttribute() 로 담아둔다.
• JSP로 포워드 해서 JSP를 렌더링 한다.

---

단순하고 실용적인 컨트롤러 - v4

앞서 만든 v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하는 등, 잘 설계된 컨트롤러이다. 그런데 실제 컨트롤러 인터페이스를 구현하는 개발자 입장에서 보면, 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 조금은 번거롭다.

좋은 프레임워크는 아키텍처도 중요하지만, 그와 더불어 실제 개발하는 개발자가 단순하고 편리하게 사용할 수 있어야 한다. 소위 실용성이 있어야 한다.

ControllerV4
이번 버전은 인터페이스에 ModelView가 없다. model 객체는 파라미터로 전달되기 때문에 그냥 사용하면 되고, 결과로 뷰의 이름만 반환해주면 된다.

 

MemberFormControllerV4 - 회원 등록 폼

정말 단순하게 new-form이라는 뷰의 논리 이름만 반환하면 된다.

 

MemberSaveControllerV4 - 회원 저장

model.put("member", member)

모델이 파라미터로 전달되기 때문에, 모델을 직접 생성하지 않아도 된다.

 

MemberListControllerV4 - 회원 목록

 

FrontControllerServletV4

FrontControllerServletV4 는 사실 이전 버전과 거의 동일하다.

 

모델 객체 전달 Map model = new HashMap<>(); //추가

모델 객체를 프론트 컨트롤러에서 생성해서 넘겨준다.

컨트롤러에서 모델 객체에 값을 담으면 여기에 그대로 담겨있게 된다.

 

뷰의 논리 이름을 직접 반환

컨트롤러가 직접 뷰의 논리 이름을 반환하므로 이 값을 사용해서 실제 물리 뷰를 찾을 수 있다.

 

정리

이번 버전의 컨트롤러는 매우 단순하고 실용적이다. 기존 구조에서 모델을 파라미터로 넘기고, 뷰의 논리 이름을 반환한다는 작은 아이디어를 적용했을 뿐인데, 컨트롤러를 구현하는 개발자 입장에서 보면 이제 군더더기 없는 코드를 작성할 수 있다.

또한 중요한 사실은 여기까지 한 번에 온 것이 아니라는 점이다. 프레임워크가 점진적으로 발전하는 과정 속에서 이런 방법도 찾을 수 있었다. 프레임워크나 공통 기능이 수고로워야 사용하는 개발자가 편리해진다.

프레임워크나 공통 기능이 수고로워야 사용하는 개발자가 편리해진다.

---

인프런 김영한 님의 스프링 MVC 1편을 듣고 작성한 글입니다.

https://inf.run/5q6D

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의