* 이 포스팅은 부산대학교 2023 백엔드 미니 부트캠프 2주차 학습 내용을 정리한 글입니다.

모델 1 방식

모델 1은 뷰와 로직을 모두 JSP 페이지 하나에서 처리하는 구조이다.

예를 들어 메인 페이지, 회원 페이지, 게시판 페이지가 있는 웹 어플리케이션을 가정하자. 모델 1 방식은 클라이언트가 각 페이지 JSP 파일로 직접 요청을 보내는 구조이다. 이런 구조의 웹 어플리케이션은 공통처리가 불가능하다.

정리하면 다음 특징을 가진다

• 통합된 레이어: 뷰 로직과 비즈니스 로직이 JSP 파일 내에서 혼합되어 구현된다. UI와 서버 로직이 분리되지 않아 코드 재사용성이 낮고, 유지보수가 어려움.
• 서블릿 & JSP: 클라이언트 요청은 서블릿이 받고, 서블릿은 비즈니스 로직을 처리하여 JSP로 결과 전달. JSP는 서블릿에서 받은 데이터로 HTML을 생성하고 클라이언트에게 응답 보냄.
• 직접 요청 처리: 클라이언트 요청은 JSP 페이지 혹은 서블릿이 직접 처리함. 라우팅이나 컨트롤러 레이어 없이 동작함.
• 제한된 재사용성과 확장성: 작거나 단순한 어플리케이션에는 적합할 수 있지만, 로직 분리가 없어 확장 및 보수가 어려움.

FrontController 탄생

위 그림과 같이 중복되는 로직을 일차적으로 처리하기 위해서 프론트 컨트롤러를 사용한다. 하지만 프론트 컨트롤러만 있는 구조는 아직 불완전하다.

@WebServlet("*.do")
public class FrontController extends HttpServlet {
    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        // 공통 로직 처리
    }

1. 다이렉트로 JSP 호출을 막아야 한다.
2. 비즈니스/UI 로직 분리가 필요하다.
3. FrontController에서 요청 뒤, View에 재요청을 하면 request 데이터가 손실된다. request 데이터가 새로 만들어지기 때문이다.
4. 3을 해결하기 위해 세션을 사용하면 서버 동작에 악영향을 미친다.

다이렉트 JSP 호출을 막기 위해서 WEB-INF 폴더에 JSP 파일을 숨긴다.

또 View 재요청시 request 데이터 손실을 방지하기 위해 RequestDispatcher를 사용한다.

	@Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    	...
        req.getRequestDispatcher("/WEB-INF/views/해당_JSP.jsp").forward(req, resp);
    }

MVC 패턴

1. 모델: 데이터와 비즈니스 로직을 관리
2. 뷰: 레이아웃과 화면을 처리함.
3. 컨트롤러: 명령을 모델과 뷰 부분으로 라우팅.

• 최초 요청은 FrontController로 받아 공통처리
• 적절한 컨트롤러를 요청
• 컨트롤러가 데이터 필요 시, Model의 도움을 받고 Request에 저장 후 View를 찾아 응답함.
• 데이터만 필요 시, Model의 도움을 받고, 데이터를 그대로 응답함.
• 데이터가 필요 없을 때, View를 찾아 응답함.
• View를 찾을 때 재요청이 필요 → Redirect라고 함: Request에 저장된 데이터가 날아감 → RequestDispatcher를 사용하여 Request를 유지함.