지금까지 우리는 V1~V4까지 MVC 패턴을 직접 개선해가면서 코드를 작성해보았다 정리하자면 다음과 같은 점진적 개선과정을 거쳤다 v1: 프론트 컨트롤러 도입을 통해 공통처리를 가능하게 했다 이로써 프론트 컨트롤러 이외에 다른 컨트롤러들은 서블릿 컨트롤러로 생성할 필요가 없다(@WebServlet 사용 필요 X) v2: view 분류 단순 반복되는 view forwarding 프로세스를 MyView 객체의 생성을 이용하여 개선했다. MyView의 render 메서드를 통해 RequestDispatcher를 생성하고 forward를 함으로써 JSP에 request, response를 전달했다. 이 객체의 생성은 viewPath 절대경로를 받음으로써 일어난다(생성자의 인자로 절대경로를 받는다) v3: mod..
단순하고 실용적인 컨트롤러 V4 앞서 만든 V3 컨트롤러의 경우 서블릿 종속성을 제거하고 뷰 경로의 중복을 논리 뷰 이름을 반환함으로써 제거했다. 그러나 실제 컨트롤러 인터페이스를 구현하는 개발자 입장에서 항상 ModelView 객체를 생성/반환하는 것은 번거롭다 좋은 프레임워크는 아키텍쳐도 중요하지만, 그와 더불어 개발자 편의성도 중요한 요소 중 하나이다 대표적으로 스프링이 등장하기 전 EJB는 아키텍쳐 관점에서는 좋은 프레임워크였지만, 개발자 편의성에 있어 다소 떨어졌다. 그래서 스프링이 등장한 이후로 거의 사장되었다고 한다. 따라서 좋은 웹 프레임워크는 좋은 아키텍쳐 설계에 더해, 개발자들이 쓸 수 있도록 실용성이 있어야 한다. 이제부터 V3를 조금 더 개발자가 쓰기 편리하게 설계를 변경해보겠다 기..
이전 과정에서는 RequestDispatcher와 viewName 그리고 forward 메서드를 MyView 클래스와 render 메서드를 통해 리팩터링함으로써 중복을 제거하였다. 하지만 여전히 코드를 보면 물리 저장 Path의 중복이 반복되고 있고 컨트롤러 입장에서는 사실 HttpServletRequest, HttpServletResponse가 굳이? 필요하지 않을 수도 있다 (서블릿에 종속적이지 않게 설계, 즉 서블릿 기술을 몰라도 동작할 수 있다) -> 이렇게 하면 테스트도 간편해지고 간결해지는 효과를 낼 수 있다 request 객체를 Model로 사용하는 대신 별도의 Model 객체를 만들어서 반환하는 방법이 해결책이 된다! 그리고 컨트롤러가 뷰의 논리 이름을 반환하고 실제 물리 위치의 이름은 프..
이전에 논의했던 대로 v2 버전에서는 viewPath의 반복되는 등장과 RequestDispatcher의 중복 그리고 forward 로직의 중복을 해결해보겠다. 이전에는 컨트롤러가 직접 JSP에 forward를 통해 request와 response를 전달한 것과 다르게 이번에 Controller는 MyView를 반환한다 FrontController는 반환된 MyView 객체에서 render()를 호출하게 되고 이 render() 객체는 아까 중복되었던 viewPath와 RequestDispatcher 그리고 forward를 포함한다 즉, MyView에 의해 forward가 일어난다. 정리하면 MyView의 역할은, 컨트롤러에 의해 반환된 내용을 갖고 view에 request, response 객체를 넘기..
