[Spring MVC] MVC Architecture

(참고: Spring MVC Framework를 학습하기 이전에 단순히 기본 MVC 패턴을 이해하기 위한 글입니다)

 

Web Server / Servlet / JSP와 HTTP 요청 데이터 그리고 HTTP 응답 데이터에서 클라이언트와 서버가 소통하는 방법을 살펴보았었다

이전에는 이를 바탕으로 Servlet과 JSP를 활용하여 개발을 진행했었다고 한다

하지만 비즈니스로직 뿐만 아니라 뷰로직을 함께 포함하여 작성해야 했었기 때문에

뷰와 비즈니스로직의 변경 사이클이 다름에도 불구하고 하나를 수정하게 되면 서로 영향을 주었다

이러한 문제 때문에 복잡한 로직을 구현하는 순간부터 유지보수 지옥이 시작되었다고 한다

 

이러한 문제점을 타파하기 나온 것이 바로 MVC 패턴이다

 

MVC 패턴

웹 애플리케이션이라면 보통 MVC 패턴을 사용하는데

MVC는 Model, View , Controller 이 세 가지의 역할을 나눈 패턴이다

Controller : 데이터와 비즈니스 로직 사이의 상호 동작을 관리한다

HTTP 요청을 받아 파라미터를 검증하고, 비즈니스 로직을 실행한다

또한 뷰에 전달할 데이터를 조회해서 모델에 담는 역할을 한다

 

Model : 애플리케이션의 정보, DB, 데이터

뷰에 출력할 데이터를 담는 역할을 한다. 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주기 때문에

뷰는 비즈니스 로직이나 데이터 접근을 신경쓰지 않아도 되고 화면만을 렌더링 할 수 있게 되었다

 

View : 사용자에게 보여지는 화면

모델에 담겨있는 데이터를 사용하여 화면을 렌더링 하는데 집중한다

 

MVC 패턴의 작동을 좀 더 자세하게 풀어보자면 아래와 같다

1) 컨트롤러 호출

클라이언트가 컨트롤러를 호출하게 되면 컨트롤러는 요청데이터(파라미터 등의) 값을 받아온다

또한 클라이언트의 요청이 맞는지 검증하여 만약 잘못 된 요청일 경우 400 에러 등의 에러를 발생시킨다

 

2) 비즈니스로직 호출

요청 로직을 검증한 컨트롤러는 요청에 맞게

비즈니스 로직을 호출하여 데이터를 저장하거나 상품 주문하는 등의 로직을 호출한다

 

3) 데이터 전달

비즈니스 로직을 통해서 얻어온 결과 데이터를 모델에 전달한다

(예를 들어 회원조회라면 조회한 결과 목록을 모델에 전달)

 

4) 뷰 호출

클라이언트에게 응답할 뷰를 호출

 

5) 데이터 참조

호출 된 뷰는 결과 데이터를 참조하여 뷰를 렌더링 함

 

6) 응답

렌더링 된 뷰의 결과물이 클라이언트에게 응답된다

 

이렇게 MVC 패턴을 사용하여 각각의 역할을 분리하면서 더 깔끔하고 직관적인 코드 작성이 가능해졌다

하지만 공통 처리 등의 문제나 중복, 코드의 재활용성이 떨어진다는 한계점이 존재하여

스프링에서는 Spring MVC Framework를 지원하며 이러한 단점을 모두 보완하였다

 

---

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

 

참조 링크:

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard

https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%8D%B8-%EB%B7%B0-%EC%BB%A8%ED%8A%B8%EB%A1%A4%EB%9F%AC