📗Spring MVC Study [ MVC ]

MVC 패턴

개요

너무많은 역할

• 하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많으녀 역할을 하게되고, 결과적으로 유지보수가 어려워진다.
• 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 손대야 하며, UI를 변경 할 일이 있어도 비즈니스 로직이 함께 있는 해당 파일을 수정해야 한다.

변경의 라이프 사이클

• 진짜 문제는 뷰 로직과 비즈니스 로직 둘 사이에 변경의 라이프 사이클이 다르다는 점이다.
• 예를 들어서 UI를 일부 수정하는 일과 비즈니스 로직을 수정하는 일은 각각 다르게 발생할 가능성이 매우 높고 대부분 서로에게 영향을 주지 않는다.
• 변경 라이프 사이클이 다른 부분을 하나의 코드로 관리하는 것은 유지보수하기 좋지 않다.

기능 특화

• JSP와 같은 뷰 템플릿은 화면을 렌더링 하는데 최적화 되어 있기 때문에 이 부분의 업무만 담당하는 것이 가장 효과적임.

Model View Controller

• MVC 패턴은 하나의 서블릿이나, JSP로 처리하던 것을 컨트롤러(controller)와 뷰(view)라는 영역으로 서로 역할을 나눈 것을 말한다.
• 웹 애플리케이션은 보통 이 MVC 패턴을 사용한다.

컨트롤러

• HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한다.
• 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다.

모델

• 뷰에 출력할 데이터를 담아둔다.
  뷰가 필요한 데이터는 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 된다.
• 화면을 렌더링 하는 일에 집중

뷰

• 모델에 담겨있는 데이터를 사용해서 화면에 그리는 일에 집중 (HTML 생성 부분을 의미)

• 위와 같은 그림이 우리가 MVC모델이라고 생각했던 그림

MVC 패턴의 한계

• MVC 패턴을 적용한 덕분에 컨트롤러의 역할과 뷰를 렌더링 하는 역할을 명확하게 구분할 수 있다.
• 뷰는 화면을 그리는 역할에 충실 -> 코드가 깔끔하고 직관적, 단순하게 모델에서 필요한 데이터를 꺼내고, 화면을 생성
• 하지만 컨트롤러는 중복이 많고, 필요하지 않은 코드들도 많이 보임

공통 처리가 어려움

• 기능이 복잡해질 수 록 컨트롤러에서 공통으로 처리해야 하는 부분이 점점 더 많이 증가
• 중복 부분을 메서드로 묶에서 사용하면 될 것 같지만 결과적으로 해당 메서드를 항상 호출해야 한다.
• 이 문제를 해결하려면 컨트롤러 호출 전에 먼저 공통 기능을 처리해야 한다. -> 프론트 컨트롤러 패턴
• 스프링 MVC의 핵심도 이 프론트 컨트롤러에 있음.

📭 Reference

• 인프런 김영한 강사님의 스프링 MVC
• 링크 : https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1