[스프링 MVC] #3

김영한님의 스프링 MVC 1편 강의를 듣고 복습 겸 정리하는 포스팅입니다!!

아직 공부하는 중인 학생이라 부족한 부분이 있을 수 있습니다. 

혹시라도 틀린 부분이 있다면 언제든지 댓글로 남겨주세요. 감사합니다 🙇‍♂️

---

처음에는 JSP 하나로 화면도 만들고, 로직도 처리하면 편해 보일 수 있습니다.
하지만 시간이 지나면서 모든 코드가 JSP에 노출되고, 역할이 뒤섞이기 시작하면 유지보수가 점점 어려워집니다.

서블릿은 자바 코드를 실행하는 데 최적화,JSP는 화면을 렌더링하는 데 최적화되어 있기 때문에
각자의 역할에 맞게 사용하는 것이 가장 효과적입니다.

 

MVC(Model-View-Controller) 패턴을 사용하면 다음과 같이 역할을 나눌 수 있습니다

컨트롤러 (Controller)

• HTTP 요청을 받아 요청 파라미터를 검증하고,
• 비즈니스 로직을 실행한 뒤,
• 뷰에 전달할 데이터를 모델에 담아 넘겨줍니다.

모델 (Model)

• 뷰에 출력할 데이터를 담는 객체입니다.
• 뷰는 이 모델을 통해 필요한 데이터를 얻고 화면을 렌더링합니다.
• 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 됩니다.

 뷰 (View)

• 모델에 담긴 데이터를 읽어 화면에 출력하는 역할만 수행합니다.
• 복잡한 로직 없이, 화면 렌더링에만 집중할 수 있습니다.

MVC 흐름 요약

1. 사용자가 컨트롤러를 호출합니다.
2. 컨트롤러는 요청 파라미터를 꺼내고, 요청이 유효한지 검증합니다.
3. 검증이 끝나면 비즈니스 로직(서비스/리포지토리)을 호출해 데이터 처리(예: 저장, 조회)를 합니다.
4. 처리된 결과를 모델에 담아 뷰로 전달합니다.
5. 뷰는 모델에서 필요한 값을 꺼내 화면을 구성합니다.

보통은 서비스 계층을 따로 만들어 비즈니스 로직을 처리합니다.
이렇게 하면 로직을 재사용하기 쉽고, 컨트롤러는 흐름만 관리하게 되어 훨씬 깔끔해집니다.

 

MVC  패턴의 한계 

강의에서 MVC 패턴을 적용한 덕분에 구조는 깔끔해졌지만, 중복 코드가 발생하는 문제를 발견할 수 있었습니다. 

 

아래 사진 3개의 클래스 하단을 보면, 모두 다음 코드가 반복되고 있습니다. 

RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);

메서드로 분리할 수도 있지만, 결국 매번 직접 호출해야 한다는 점은 변하지 않는다. 

 

또한 모든 컨트롤러 메서드 파라미터에 항상 HttpServletRequest, HttpServletResponse를 넣어야 한다. 

 HttpServletRequest request, HttpServletResponse response

 

기능이 복잡해질수록 컨트롤러에서 공통으로 처리해야 하는 부분이 증가할 것이다. 

• 공통기능을 메서드로 추출할 수 있지만
  • 매번 직접 호출해야 합니다.
  • 호출을 빼먹으면 오류가 발생합니다.

절대경로 & 상대경로

절대경로 

• /로 시작하는 경로
• 항상 고정된 위치로 요청을 보냄
• 아래와 같은 경우에는 http://localhost:8080/save로 요청됨

<form action="/save" method="post">

 

상대경로

• /로 시작하지 않는 경로
• 현재 페이지(URL)의 상대적인 위치를 기준으로 동작 
• 현재 계층 경로가 /servlet-mvc/members/ 라면 아래의 요청은 http://localhost:8080/servlet-mvc/members/save로 요청됨

<form action="save" method="post">