MVC 패턴의 등장 배경
하나의 서블릿 혹은 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리한다면, 너무 많은 역할을 하게 되어 유지보수가 어렵다.
또한, UI를 일부 수정하는 일과 비즈니스 로직을 수정하는 일은 변경 시점이 다를 가능성이 매우 높다. 따라서 변경의 라이프 사이클이 다른 부분을 하나의 코드로 관리하는 것은 유지보수하기 좋지 않다.
특히, JSP 같은 뷰 템플릿은 화면을 렌더링 하는데 최적화 되어 있기 때문에 이 부분의 업무만 담당하는 것이 좋다.
MVC 패턴을 사용하면 JSP나 서블릿으로 처리하던 것을 컨트롤러, 모델, 뷰라는 영역으로 서로 역할을 나눠 처리할 수 있다.
참고 :
https://s-y-130.tistory.com/113
MVC 패턴이란?
MVC 패턴은 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다. MVC는 Model, View, Controller로 구성되는데, Model은 애플리케이션의 정보(데이터)를 나타내며, View는 텍스트나 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, Controller는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.
모델(Model)
모델은 뷰에 출력할 데이터를 담아둔다. 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면을 렌더링 하는 일에 집중할 수 있다.
모델은 사용자가 편집하고자 하는 모든 데이터를 가지고 있어야 한다. 예를 들어 화면 안에 특정 글자를 표현하기 위해서는 글자 내용, 글자의 위치, 글자의 포맷 등의 정보를 가지고 있어야 한다.
모델은 뷰나 컨트롤러에 대해서 어떤 정보도 알지 못한다.
뷰(View)
뷰는 모델에 담겨있는 데이터를 사용해 화면을 그리는 일에 집중한다. 즉, 데이터를 기반으로 사용자들이 보는 화면을 그리는 역할을 한다.
뷰는 모델이 가지고 있는 정보를 따로 저장하지 않는다. 화면에 표시하고 나면 그만일 뿐, 데이터를 따로 저장하지 않는다.
뷰는 모델이나 컨트롤러의 동작 방식을 알지 못한다. 그저 데이터를 받으면 화면에 표시해주는 역할을 할 뿐이다.
컨트롤러(Controller)
컨트롤러는 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다. 컨트롤러 자체에 비즈니스 로직을 두기 보다는 서비스(Service)라는 계층을 별도로 만들어서 처리한다. 컨트롤러는 이 서비스를 호출해서 비즈니스 로직을 실행하게 된다.
컨트롤러는 모델이나 뷰에 대해서 알고 있다. 모델이나 뷰는 서로의 존재를 모르지만, 변경 사항이 있을 경우 외부로 알리고 수신한다. 이는 컨트롤러가 중간에서 중재하기 때문이다. 따라서 컨트롤러는 모델이나 뷰에 대한 사항에 대해 알고 있어야 한다.
컨트롤러는 모델이나 뷰의 변경을 모니터링하며, 변경 통지를 받아 이를 해석한 뒤 통지하게 된다.
MVC1
우리가 흔히 사용하고 있는 MVC패턴은 사실 MVC1, MVC2 아키텍쳐에서 발전된 패턴이다.
MVC1 패턴이란, 브라우저(사용자)로부터 요청이 들어오면 DB로부터 필요한 데이터를 받은 Model 객체(Java Bean)를 JSP 페이지(View)에 담아 응답을 보내는 패턴이다.
위의 구조를 봤을 때 JSP가 View와 Controller 역할을 모두 담당하기 때문에 JSP Page내에 너무 많은 코드가 들어가 가독성이 떨어질 뿐만 아니라 복잡해질 가능성이 생긴다.
이러한 점을 보완해 Controller 역할을 하는 servlet(서블릿)이 추가된 MVC2패턴이 등장하게 된다.
MVC2
MVC2 패턴의 서블릿은 요청에 대한 비지니스 로직을 처리한 후, 이를 JSP 파일에 반영하는 역할을 수행한다.
Spring MVC
spring framework에서 MVC2 모델을 좀 더 발전시켜 Sring MVC가 등장했으며 이는 MVC2 모델이 기반인 웹 모듈이다.
Spring MVC에 대한 내용은 다음 글을 참고하자.