- 어댑터 패턴을 사용해 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 해보겠다.
- 핸들러 매핑 정보를 찾으면 해당 컨트롤러를 처리할 수 있는 어댑터를 찾아, 프론트 컨트롤러가 핸들러 어댑터를 통해 컨트롤러를 호출한다.
- 이제 컨트롤러를 핸들러라고 부르겠다.
-
프론트 컨트롤러가 핸들러 매핑 정보에서 핸들러를 찾아오면, 핸들러를 처리할 수 있는 어댑터(v3,v4...)를 꺼낸다. 이 어댑터를 꺼내는 메소드가 supports 라는 메소드다.
-
handle은 핸들러를 호출한다.
- 핸들러 어댑터 인터페이스를 세팅한다.
- v3 핸들러 어댑터를 만들어보겠다. supports를 통해 핸들러가 컨트롤러v3를 지원할 수 있는지 확인한다.
- supports를 통해 걸러진 V3전용 핸들러를 V3로 캐스팅해 컨트롤러 변수에 담는다.
- process를 위해 v3에서 사용했던 paraMap을 만드는 메소드를 가져와 paraMap에 request를 넣어 만들어 준다.
- paramMap을 컨트롤러를 process할 때 파라미터로 넣어 모델뷰 변수 mv에 넣고 이를 리턴한다.
- 이제 V5의 프론트 컨트롤러를 생성해 준다.
- 위 controllermap이 기존에 쓰던 방식이고 아래 handlerMappingMap이 이제 사용할 방식이다. 기존에는 들어갈 컨트롤러를 정확히 명시해서 Map에 넣었지만(ControllerV4) 이제 아무 컨트롤러나 다 들어갈 수 있어야 하므로 Object를 넣는다.
- 여러 어댑터 중에 하나를 찾는 방식을 써야 하므로 리스트 형식의 handlerAdapters를 만든다.
- 생성자를 만들고 v3 매핑 정보를 핸들러에 넣은 뒤 v3 핸들러 어댑터를 핸들러 어댑터 리스트에 넣어준다.
- 메소드화 시켜 보기 편하게 해준다.
- 이제 service를 만들어 준다. 요청이 오면 URI를 handlerMappingMap으로 보내서 해당 핸들러를 찾는다
- 이 과정은 통째로 메소드화 한다.
- 이제 핸들러 매핑 정보를 통해 핸들러를 조회했으므로, 이제 핸들러를 처리할 핸들러 어댑터를 찾아와야 한다.
- handlerAdapters를 for문 루프를 돌며 찾아온다. 만약 어댑처가 핸들러를 지원하면(if supports handler) 핸들러를 찾아오는 코드다.
-
getHandlerAdapter 이름으로 메소드화 한다.
-
이제 핸들러를 찾아오고, 핸들러의 어댑터를 찾아오는 일 까지 완료했다.
- 핸들러 어댑터를 찾지 못하는 경우를 예외처리까지 해준다.
- 이제 handle 로 어댑터를 호출해 모델뷰로 반환해주면 된다.
- viewResolver 도 가져와 물리 주소 변환까지 완료해준다.
- 서버를 돌렸는데 404 에러가 났다. 핸들러 매핑 정보를 잘못 설정해서 그렇다.
- /v3 로 되어있었는데 /v5/v3 로 바꿔준다.
- 서버에서 동작 확인
하마드