스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 섹션4. MVC 프레임워크 만들기

전에 얘기했던 수문장 어쩌구 하는건 프론트 컨트롤러였다.

v1부터 v5까지 단계적으로 계선해 나간다. 강의라서 그런것도 있지만 실제로도 구조를 바꿀 때 하나씩 바꾸고 잘되는지 확인 되었으면 그 다음에 바꾸고 하는걸 추천한다 함.

일단 v1은 이런 구조로 바꾼다.

 

Front Controller를 위 플로우차트처럼 그대로 구현함. 이제 각각의 클래스가 url을 받지 않기 때문에, 각각의 컨트롤러엔 @WebServlet이 없고 프론트 컨트롤러에만 @WebServlet이 붙어있다. Map형태로 찾고 해당 행동을 수행하는 나머지 코드들은 기존의 것을 그대로 가져왔다.

 

 

v2는 뒤의 forward 부분만 MyView 클래스 만들어서 따로 뺌.

지금 문제는 모델을 아직 안 사용했고, request랑 response가 필요 없는 애도 형식 상 받아야 되는 것. 이걸 v3에서 개선한다.

 

 

v3부터는 좀 복잡해진다.

프론트 컨트롤러만 더러운 일들을 잔뜩하고, 앞으로 많이 만들게 될 컨트롤러에는 최대한 간단하게 하고 싶다는게 목적이다. 그래서 servlet request, response는 컨트롤러가 몰라도 되고, Controller와 view는 오로지 Model을 통해서만 데이터를 주고받는다. Controller에서 데이터를 받아서 해석하거나 주고 프론트 컨트롤러는 컨트롤러가 준 모델뷰를 보는데, 모델 뷰에는 내가 무슨 역할이었고 무슨 변수를 주면 되는지만 들어있다. 이 사실을 viewResolver를 통해 진짜 view로 변환하고 servlet response로 응답한다.

 

컨트롤러에서 프론트 컨트롤러에게 모델뷰로써 나의 대답은 이렇게 해석하면 된다고 name으로 알려주고 정보는 Map에 넣는다. 프론트 컨트롤러는 컨트롤러가 알려준 이름과 받은 정보가 담긴 Map을 가지고 어떤 뷰에 넣고 해석할 지 알려준다.

뷰는 모델뷰를 통해 컨트롤러로 부터 이미 받은 이름과 정보를 servlet response에 넣을 수 있도록 변환한 후 반응한다.

이렇게 해서 컨트롤러는 servlet의 존재도 모른 채 그냥 paramMap에서 정보가 string으로 왔으니 알아서 잘 해석하고 준다.

 

 

v4는 위 v3가 구조적으로는 사실 완벽해서 뭐 더 할것도 없다. 하지만 사용자인 개발자 입장에서는 코드 중복도 있고 ModelView에 이름따로 데이터 따로 전달해주고 이런게 불편하다고 사용성 조금 개선된 버전.

달라진건 원래 컨트롤러가 ModelView를 생성해 이름과 데이터를 같이 줬는데, 코드를 줄이기 위해 데이터는 모델로 주고 뷰한테 어떤걸 보여줘야 하는지는 viewName을 반환하는 방식으로 전달한다.

 

 

v5는 중간에 어댑터 개념을 만들어서 v3과 v4를 원하는걸로 사용하기.

기본적인 구조는 URL을 통해 v5중에서도 v3나 v4를 다음 디렉토리로 하여 어느것을 쓰고 싶은지 정하고, 이걸 각 버전에 맞는 컨트롤러에 연결시켜서 사용한다.

핵심은 getHandlerAdapter로 v3의 컨트롤러를 가져온다. v3 핸들러 어뎁터는 그냥 v3의 코드를 사용한다.

 

 

v4도 위와 비슷하게 연결하지만, v4는 string인 modelName을 받지만 v5가 ModelView를 받기 때문에 어댑터에서 v4를 실행하고 마지막에 ModelView로 바꿔야 한다. 이 부분들이 있어서 어댑터라고 하는거임.

 

 

 

이렇게 설계를 잘 해놓으면 구조를 바꾸지 않아도 객체만 갖다끼우면 다른 객체를 쓸 수 있다. 저기도 요청하는 url만 바꾸면 원하는 v3,v4 막 선택해서 할 수도 있고, 코드 상에서도 쉽게 변경 가능.