멤버를 저장하는 MemberSaveServlet은 Member 객체를 만들어 MemberRepository에 저장한 후, PrintWriter를 사용하여 결과화면용 HTML을 동적으로 만들어서 응답한다.
멤버를 조회하는 MemberListServlet은 memberRepository의 findAll()을 통해 모든 회원을 조회한 후에, 마찬가지로 PrintWriter와 for문을 돌며 HTML을 사용한다.

서블릿과 자바코드만으로 HTML을 만들어보면 서블릿 덕분에 동적으로 원하는 HTML을 만든다. 하지만 매우 복잡하고 비효율적이다.
서블릿으로 재발 시 View화면을 위한 HTML이 자바코드에 섞여 지저분하고 복잡하다.
자바코드로 HTML을 만들어 내는 것보다, 템플릿엔진을 활용하여 HTML에 동적으로 변경해야하는 부분만 자바코드를 넣어서 동적으로 변경한다. 템플릿 엔진의 예: JSP, Thymeleaf - 화면 랜더링에 최적화되어 있다.
회원 조회 JSP를 만들어 관리하면 <% ~~ %> 부분에 자바 코드를 입력할 수 있다.

JSP를 사용하면 뷰를 생성하는 HTML 작업을 가져가고 중간중간 동적으로 변경이 필요한 부분에만 자바 코드를 적용한다.
하지만, 코드의 상위 절반은 결과 column에 대해 HTML로 보여주는 뷰 영역이고 나머지 절반은 회원 목록을 출력하기 위한 비즈니스 로직이다. 그렇기 때문에 jsp에 자바코드나 데이터를 조회하는 레포지토리 등 다양한 코드가 모두 노출되어 있다. 이 경우 유지보수 하기 어렵다.
하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많은 역할을 하게되고 결과적 으로 유지보수가 어려워진다.
(UI와 비즈니스 로직 수정은 다르게 발생한다 -> 변경의 라이프 사이클이 다르다) 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 손대야 하고, UI를 변경 할 일이 있어도 비즈니스 로직이 함께 있는 해당 파일을 수정해야 한다.

비즈니스로직은 다른 곳에서 처리하고 JSP는 목적에 맞게 HTML로 View를 구성하는 일에 집중하도록 만든 것이 MVC 패턴이다. MVC 패턴은 지금까지 학습한 것 처럼 하나의 서블릿이나, JSP로 처리하던 것을 컨트롤러(Controller)와 뷰(View)라 는 영역으로 서로 역할을 나눈 것을 말한다. 웹 애플리케이션은 보통 이 MVC 패턴을 사용한다.
- 컨트롤러: HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다.
- 모델: 뷰에 출력할 데이터를 담아둔다. 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로 직이나 데이터 접근을 몰라도 되고, 화면을 렌더링 하는 일에 집중할 수 있다.
- 뷰: 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중한다. 여기서는 HTML을 생성하는 부분을 말한다.

(+서비스 계층: 컨트롤러에 비즈니스 로직을 둘 수 있지만, 컨트롤러가 너무 많은 역할을 담당하게 된다. 그래서 일반적 으로 비즈니스 로직은 서비스(Service)라는 계층을 별도로 만들어서 처리한다. 그리고 컨트롤러는 비즈니스 로직 이 있는 서비스를 호출하는 역할을 담당한다.
MVC 패턴을 적용한 덕분에 컨트롤러의 역할과 뷰를 렌더링 하는 역할을 명확하게 구분할 수 있다. 특히 뷰는 화면을 그리는 역할에 충실한 덕분에, 코드가 깔끔하고 직관적이다. 단순하게 모델에서 필요한 데이터를 꺼내 고, 화면을 만들면 된다
서블릿을 컨트롤러로 사용하고, JSP를 뷰로 사용해서 MVC 패턴을 적용한다. HttpServletRequest를 Model로 사용한다. request가 제공하는 setAttribute()를 사용하면 request 객체에 데이터를 보관해서 뷰에 전달가능하다.
뷰는 request.getAttribute()를 사용해서 데이터를 꺼낸다.
하지만 jsp가 아닌 thymeleaf 같은 다른 뷰로 변경한다면 전체코드를 다 변경해야 한다.
기능이 복잡해질 수록 컨트롤러에서 공통기능을 메서드로 뽑으면 될 것 같지만, 결과적으로 해당 메서드를 항상 호출하고 호출코드를 까먹었을 시 문제가 된다.
이때, 공통기능을 처리해야 하는 것은 프론트 컨트롤러 패턴으로 할 수 있다.
| [스프링] 스프링 MVC 1편 - Chapter6 스프링 MVC 기본기능 (0) | 2024.01.23 |
|---|---|
| [스프링 MVC 1편] Chapter4. MVC 프레임워크 만들기 (0) | 2024.01.16 |
| [스프링 MVC 1편] Chapter1. 웹 애플리케이션의 이해 (0) | 2024.01.04 |