스프링 MVC 1편

🚀 서블릿

HTTP 메세지의 파싱과정을 HttpServletRequest를 통해 쉽게 만들어줌 하지만 클라이언트에게 값을 보여줄때 자바 코드안에 html을 넣어야 한다는 점이 너무 불편했음

🚀 jsp

결과적으로 다 서블릿으로 바뀌지만 HTTP를 일일이 getwriter+write 할필요가 없어서 서블릿 보다 편했다 서블릿은 자바가 메인에 html이 서브인 느낌이라면 jsp는 html이 메인에 자바가 서브인 느낌이다. 하지만 이것 또한 자바로직과 html로직이 섞여 있기 때문에 유지보수하기가 어려워 보였고 하나의 파일이 사이즈가 너무 커질것 같았다

🚀 MVC 모델(controller:서블릿 + view:jsp)

확실히 jsp에 한꺼번에 코드를 넣는것보단 유지보수가 편해보였다 유지보수에는 디자인 관련 부분이 있을때도 있고 로직 부분에서 보수를 해야할 상황이 따로 있는데 이 둘을 분리 했기 때문이다. 하지만 서블릿에서 값을 받아서 getattribute하고 request.getRequestDispatcher("jsp위치").forward(request, response)가 너무 반복되는 느낌을 받았다.

🚀 1차 리팩토링

FrontController라는 개념을 도입해서 서블릿부분(컨트롤러 부분)에 사용자가 요청을 하면 바로 해당 컨트롤러로 가는게 아니라 공통된 부분을 처리하고 컨트롤러로 가도록 구조를 바꾸었다 확실히 이전보다 코드가 깔끔해졌다

🚀 2차 리팩토링

컨트롤러에서 view로 이동하는 부분을 클래스로 뽑았다(myview)

🚀 3차 리팩토링

1. 서블릿에 종속적이지 않게 modelview 객체를 만들고 FrontController만 서블릿을 사용하도록 만들었다
2. view로 이동하는 이름을 view resolver로 중복부분을 뽑아 내었다

🚀 4차 리팩토링

컨트롤러가 modelview 객체를 FrontController에게 반환하는것이 아니라 논리 이름을 반환하도록 하였다. modelview를 만드는 부분이 컨트롤러에서 없어져서 훨씬 코드가 깔끔해졌다

🚀 5차 리팩토링

3차 리팩토링한 내용과 4차 리팩토링한 내용에서 각각 컨트롤러들이 반환하는값이 다른데(modelview, 논리 이름) 이를 어뎁터라는 개념을 이용해서 서로 다른 값을 반환하는 컨트롤러들을 modelview를 반환하도록 바꾸었다. 컨트롤러라기 보단 핸들러와 가까운 개념이 되었다.

이해가 되지 않았던 부분

request, response에 종속적이지 않으면 무엇이 좋은것인가?

1. 테스트에 용이함

핸들러란? 자동차의 핸들과 마찬가지로 클라이언트의 요청을 처리하는 처리자