이전에 MVC 패턴의 한계에 대해 언급하면서 공통처리가 어렵고 코드 중복이 발생한다는 단점에 대해 논했다. 문제를 해결하기 위해서는 수문장 역할을 하는 프론트 컨트롤러를 ControllerA, ControllerB, ControllerC 앞에 배치하면 된다. 다음과 같은 다이어그램으로 나타난다. 프론트 컨트롤러는 앞에 대표 컨트롤러 하나만 서블릿으로 설정하고 이 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출하는 기능을 한다 모든 요청이 이 프론트 컨트롤러를 거쳐 실제 컨트롤러를 호출함에 따라 실제 ControllerA, ControllerB, ControllerC가 호출되기 이전에 필요한 공통처리 메서드를 실행할 수 있다. 프론트 컨트롤러에서 알아서 찾아서 특정 컨트롤러를 호출할 것이기 때문에 Contr..
지금까지 제작한 컨트롤러들의 코드를 보면 다음과 같이 중복되는 사항이 있다는 걸 발견할 수 있다. 1. viewPath의 중복 String viewPath = "/WEB-INF/views/members.jsp"; viewPath 변수 선언의 반복과 동시에 절대경로 표시에 필요한 다음 두 요소 prefix : /WEB-INF/views postfix : .jsp 가 반복되는 것을 알 수 있다 2. 포워드 과정의 중복 RequestDispatcher requestDispatcher = request.getRequestDispatcher(viewPath); requestDispatcher.forward(request, response); 서블릿에서 뷰로 이동하기 위한 포워드 과정이 각 서블릿 별로 반복해서 등..
이전 JSP와 서블릿에서 구현하던 경우, 뷰와 컨트롤러가 하나의 코드, 서블릿 또는 JSP에 결합되어 있어 둘 중 하나를 수정하려 할때 다른 곳의 코드까지 변형하는 실수를 범하거나 한 서블릿 또는 JSP에 너무 많은 책임이 부여되어있다는 단점이 있었다. 스프링 MVC는 이런 책임의 가중을 분산(분리)를 통해 해결한다. MVC패턴에서 MVC는 모델 / 뷰 / 컨트롤러 의 약자이며 웹 애플리케이션은 보통 이런 MVC 패턴을 이용한다 컨트롤러: 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행하는 역할을 맡는다 그리고 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다. -> 주소를 검증하고, 호출하는 것에 집중한다. 세부적으로 컨트롤러에 비즈니스 로직을 함께 구현하는 경우가 있으나, 이렇게 되면 컨트롤..
JSP를 사용하려면 먼저 다음 라이브러리의 추가가 필요하다 plugins { id 'java' id 'war' id 'org.springframework.boot' version '2.7.11' id 'io.spring.dependency-management' version '1.0.15.RELEASE' } group = 'hello' version = '0.0.1-SNAPSHOT' sourceCompatibility = '11' configurations { compileOnly { extendsFrom annotationProcessor } } repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot:..
