개발은 아름다워

서블릿 -> 템플릿 엔진 -> MVC 패턴 -> FrontController 까지 왔다. 특히 FrontController를 직접 만들면서 HTTP 요청을 처리할 수 있는 다양한 버전의 Controller를 만들었다. 그렇다면 하나의 FrontController에서 다양한 버전의 Controller 들을 사용할 수 없을까?어댑터 패턴 등장다양한 버전의 Controller들은 반환 값이 다 다르다. 반환 값이 다 다르면 FrontController에서는 Controller 버전에 따라 로직을 따로 작성해야하는 번거로움이 생긴다. 따라서 Controller가 반환하는 값을 공통으로 만들어 줄 무언가가 필요한데 그것이 바로 어댑터이다. 아이폰을 충전하든, 맥북을 충전하든 결국 220v 소위 말하는 돼지코가 어..

고대의 서블릿에서 현재 Spring MVC 프레임워크까지 여정을 살펴보고 있다.서블릿 -> 템플릿 엔진 -> MVC 패턴 -> FrontController -> view -> ModelView 여정까지 오게 되었다.ModelView 까지 적용한 과정을 간략하게 적어보면1. ModelView 객체에 viewName과 controller로 부터 발생한 데이터를 model에 담는다.2. controller는 ModelView 객체를 반환한다.3. FrontController는 controller가 반환한 ModelView 객체에 있는1) viewName을 viewResolver를 통해 viewPath로 바꿈2) model에 담긴 데이터를 HttpServletRequest request객체로 데이터 전달4. v..

'작성된 코드를 보면서 이게 과연 반드시 필요한 것일까?' 라는 의문이 든적이 있지 않는가? ModelView도 같은 질문에서 시작한다.ModelView의 필요성이전 controller들의 코드를 봐보자public class MemberFormControllerV2 implements ControllerV2{ @Override public MyView process(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { return new MyView("/WEB-INF/views/new-form.jsp"); }}public class Mem..

지금까지의 고대의 서블릿 찾는 여정...서블릿 -> 템플릿 엔진 -> mvc패턴 -> FrontController 도입전에 있던 단점을 보안하며 FrontController까지 오게되었다.왜 view가 필요할까?전에 있던 단점들은 대부분 중복되는 코드들을 어떻게 하면 공통으로 쓸 수 있을까? 에 대한 고민이였다. 이번 view를 추가하는 것도 동일하다.FrontController의 controller들의 코드를 봐보자public class MemberFormControllerV1 implements ControllerV1{ @Override public void process(HttpServletRequest request, HttpServletResponse response) thro..

지난 시간 템플릿 엔진으로 요청을 처리하는 방법을 배웠다. 템플릿 엔진으로 Http 요청을 처리하니 HTML 문서 코드 부분과 동적으로 자바 코드는 넣는 부분을 나눔으로써 코드 작성이 한결 쉬워졌다. 그러나 문제는 이어진다.MVC 패턴 - 개요과도한 역할을 방지하라,,,하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많은 역할을 하게 되고, 결과적으로 유지보수가 어려워진다. 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 수정해야하고, UI를 변경 할 일이 있어도 비즈니스 로직이 함께 있는 해당 파일을 수정해야 한다. 비즈니스 로직 하나를 수정해야하는데 수천줄의 HTML 코드가 함께 있다면..?변경의 라이프 사이클진짜 문제는 비즈니스 로직과 뷰 렌더링 ..