MVC 패턴이란?

MVC 패턴은 매우 유명하고 자주 볼 수 있는 패턴이다.

MVC 란 Model View Controller의 약자다.
프로젝트의 구성 요소를 세가지 역할로 구분 짓는 패턴입니다.

출처: 오픈튜토리얼스

위 그림과 같이 사용자가 Controller를 조작하게 되면 Contoller는 Model을 변환한다.
변환된 모델을 View가 보여주게 된다.

이를 통해 유저는 모델에 직접적으로 접근 할 수 없기도 하다.

하지만 Spring이나 Express 등을 하며 MVC 패턴을 접해본 사람이라면 Service와 Repository는 뭐지? 라는 생각을 할 수 있다.

왜 MVC 패턴을 써야할까?

MVC 패턴이 가지는 장점은 유저에게 보여지는 페이지, 데이터 처리, 컨트롤, 이 3가지의 역할을 따로 구분에서 맡은 역할에 집중할 수 있게 해준다.

서로 분리되어 각자의 역할에 집중할 수 있게하여 유지 보수성, 확장성, 유연성을 증가 시키며, 중복 코딩을 감소시켜주는 효과를 준다.

Model - View- Control의 역할

앞서 말했듯이

• Model은 어플리케이션이 무엇을 할 것인지 정의한다. DB와 연동하여 유저가 입력한 데이터나 출력할 데이터를 직접적으로 다룬다.
• View는 사용자에게 시각적으로 보여지는 부분이다. (UI)
• Controller는 View와 Model의 중간 제어자 역할을 담당한다.

Contoller를 굳이 왜 써?

Controller는 말 그대로 중간 제어자다.
네비게이션 같은 기능이라고 볼 수 있는데 Model에서 처리할 수 있는 문제가 아닌가 싶을 수 있다.
하지만 Controller를 쓰는 이유는 따로 있다.

서비스가 커질 수록 A서비스, B서비스, C서비스 등등이 있다고 할 때, 이 많은 종류의 Controller를 한 파일에 꾹꾹 눌러 담으면 유지보수의 난이도가 급상승 할 것이다.

이 때 Controller를 서비스 별로 나누게 되면 A서비스는 A-Contoller 맡고 B서비스는 B-Controller가 C서비스는 C-Controller가 맡게 되면 유지보수가 훨신 쉬워지게 된다.

또한 Controller에 비지니스 로직이나 데이터 처리 등을 한번에 넣으면 컨트롤러의 역할이 여러개가 된다. 이 또한 Controller - Service - Repository 로 분리해서 사용한다.

Service는 왜 쓰이는걸까?

service는 controller를 더욱 깔끔하게 나타내기 위해 등장한 영역이다.
controller에서 너무 많은 것을 관리하게 되면 유지보수가 매우 힘들어 지기 때문에 이를 나눠 관리한다.
또한 Controller가 맡은 역할에 집중할 수 있도록 해준다.

주로 controller는 요청의 처리를 담당한다.
요청의 처리란 유저의 요청을 받아 어떤 service에 넘겨줄지 정하여 넘겨주고 로직이 끝난 뒤 나온 결과 값을 View(유저)로 보내주는 역할이다.

반면 service는 비지니스 로직의 수행을 담당한다.
데이터를 어떻게 처리하고 관리할지 등을 결정하고 데이터를 가공하여 controller에게 전달한다.

그럼 Repository는?

repository는 service와 같은 이유로 나누게 된다.
service는 비지니스 로직을 담당하지 데이터를 수정하고 삽입하는 등 직접적인 처리를 관여하진 않는다.
대신 repository가 그 부분만들 담당한다. SQL이나 queryDSL을 사용해본 사람이라면 알 것이다. DB에 데이터를 수정하기만 하는 코드도 상당히 복잡하고 길다는 사실을.

그렇기 때문에 데이터 처리는 repository를 통하는 것이다.

Contoller 영역에는...

또한 repository와 service, controller를 나누는 방식의 장점이 하나 더 있다.
이는 객체 지향의 장점이라고도 할 수 있는 부분이다.
바로 하위 객체에서 수정이 일어나도 상위 객체는 이에 대한 영향을 받지 않는 다는 점이다.

예를 들어, 인터페이스가 있다는 가정 하에 mysql DB에서 PostgreSql로 마이그래이션 해야하는 상황이 발생했다고 치자.
DB와 직접적인 소통을 하는 곳은 repository다.
그렇기에 repository 코드를 mysql에서 postgreSql에 맞게 수정하였다.
하지만 service나 controller는 동일한 인자와 return 값을 받게 되기에 repository만 수정해주는 것으로 DB를 바꿀 수 있다.

MVC 패턴의 한계점

당연하게도 MVC 패턴이 만능은 아니다.

• 서비스가 거대해 질수록 Controller가 비대하고 복잡해진다.
• 모든 데이터의 처리가 Controller를 통해서만 이뤄지기에 직관성이 떨어진다.
• 객체지향적으로 생각하기보다 MVC 패턴적으로 생각해야하는 경우가 많다.