MVC패턴이란 무엇인가?

최근 '리액트 교과서'를 읽다가

'React는 다른 MVC 프레임워크나 AngularJS의 지시자, Jade, Pug 같은 템플릿 엔진 문법에 비하면

학습 곡선이 얕고 완만하다(React는 MVC가 아니니 이러한 비교는 이쯤에서 그만 두겠다).' 라는 문장을 발견했다.

 

여기서 MVC가 무엇인가? 그리고 무엇이길래 MVC 프레임워크들이 즐비한가?

 

MVC란?

MDN에서 이를 찾아보았다.

https://developer.mozilla.org/ko/docs/Glossary/MVC

 

MVC (모델-뷰-컨트롤러) 는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다. 소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있습니다. 이러한 "관심사 분리" 는 더나은 업무의 분리와 향상된 관리를 제공합니다. MVC 에 기반을 둔 몇 가지 다른 디자인 패턴으로 MVVM (모델-뷰-뷰모델), MVP (모델-뷰-프리젠터), MVW (모델-뷰-왓에버)가 있습니다.

 

즉, 코드를 아래 3가지 부분으로 나눠서 관심사를 분리한 디자인 패턴을 말한다.

1. 모델: 데이터와 비즈니스 로직을 관리한다.
2. 뷰: 레이아웃과 화면을 처리한다.
3. 컨트롤러: 모델과 뷰로 명령을 전달한다.

 

MVC패턴은 왜 나왔나?

바로 말하자면 유지보수 때문이다. MVC패턴이 나오기 이전에는 코드의 관심사 분리없이

명령형 코드는 줄줄이 한 파일 내에 스크립트가 다 있는 방식의 개발을 많이 했나보다.

그래서 이를 개선하기 위해 코드의 패턴을 분석하여 용도를 추려보니 모델, 뷰, 콘트롤러로 나눌 수 있어보인 것이다.

 

모델 뷰 컨트롤러 예시

아래는 우테코 테코톡 제리님의 MVC 설명 영상이다. 이때 구글에 코딩을 검색했을 때 일어나는 일을 설명하는데,

이때 뷰와 모델은 서로 간섭하지 않고, 콘트롤러가 모델과 먼저 소통하고 얻은 응답값으로 뷰를 수정한다는걸 알 수 있다.

 

 

그렇다면 MVC패턴을 지키면서 개발하려면 어떻게 해야되는가?

1. 모델(model)은 콘트롤러(controller)와 뷰(view)에 의존하지 않아야 한다.

모델 코드 안에 뷰와 콘트롤러 코드가 있으면 안 된다.

예시로 클래스를 들 수 있겠다.

 

 

2. 뷰(view)는 모델에만 의존해야하고, 콘트롤러(controller)에게 의존하면 안 된다.

뷰 내부에 Model의 코드가 있을 수 있지만, 콘트롤러의 코드는 있으면 안 된다.

아까 봤던 student는 모델에 관련된 코드인데 이걸 패러미터로 받은걸 알 수 있다.

 

예시: UI 마크업 코드와 모델로부터 받은 데이터를 합해서 View가 구성된다.

 

모델로부터는 비즈니스 로직 데이터만 받아야한다.

UI가 하얀색이다 검은색이다. 글씨가 몇 폰트다 같은 것들을 모델로부터 받으면 안 된다.

 

 

3. 콘트롤러(controller)에는 모델(model)과 뷰(view) 코드가 모두 있어도 된다.

왜냐하면 콘트롤러는 모델과 뷰의 중재자의 역할을 해주기 때문이다.

 

 

4. 뷰(view)가 모델에게 데이터를 받아야한다면 꼭 콘트롤러(controller)를 거쳐 받아야한다.

뷰에는 콘트롤러에 있는 코드를 받아 보여줄수는 있지만 모델에서 직접 데이터를 받으면 안 된다고 한다.

이에 대한 이유에 대한 언급은 쉽게 찾을 수 없었는데, 아마 너무 자유자재로 쓸 수 있으면 관리하기 힘들어서가 아닐까?

 

MVC패턴을 이용하는 프레임워크들

그렇다면 MVC패턴을 사용하는 프레임워크나 라이브러리는 무엇이 있을까?

대표적으로는 Angular.js와 Python django가 있다고 한다..

(갠적으로 두 프레임워크 다 사용해본 적이 없어서 MVC패턴에 대한 구체적인 감은 안 오는거 같다.)

 

 

 

MVC 패턴의 한계점은?

1. Model과 View의 의존성을 완전히 분리시킬 수 없다.
2. 컨트롤러의 비중이 높아져 부담이 커진다면 Massive-View-Controller 현상을 피할 수 없다

라고 한다. Model은 Controller를 통해서 View와 연결된다.  그런데 이때 소수의 controller에 여러 모델과 뷰가 붙는 구조가 생길수도 있다고 한다. (그러면 이런 구조를 짜지 않기 위해 한개의 컨트롤러에는 한개의 모델만 붙이면 되는게 아닌가?) 그러나 콘트롤러에 과도한 모델과 뷰가 붙는 경향이 존재하긴 한가보다.. 다음에 사용해볼 기회가 된다면 왜 소수의 콘트롤러에 비대한 모델들이 붙게 되는지 한 번 탐구해보도록 하겠다.

 

하여튼 특정 로직에 너무 많은 다른 로직들이 의존할 때, 이 로직을 편집하는거 자체가 조금 무섭긴 하다. 수정 후 사이드 이펙트로 무엇이 나올지 예측하기가 어렵기 때문에.. 이런 문제들을 mvc구조에선 아래처럼 부른다.

Massive-View-Controller(대규모 MVC 어플리케이션)란?
MVC 패턴에서 컨트롤러의 역할이 과도하게 커지고 복잡해지는 상황을 지칭한다. 이는 주로 대규모 애플리케이션에서 발생할 수 있으며, 코드의 비대화, 재사용성 및 확장성 저하, 유지보수성 하락 및 테스트 용이성 저하 등의 문제를 야기할 수 있다.

 

 

MVC구조의 문제를 해결하려는 다른 구조들

그리고 이런 mvc구조의 문제점을 풀기 위해 아래와 같은 구조들이 나왔다고 한다.

(갠적으로 mvvm, flux와 redux를 공부해보면서 mvc와 한 번 더 비교하며 학습해봐야겠다.)

• MVVM
• MVP
• MVW
• Flux
• Redux
• RxMVVM

 

리액트는 MVC패턴에 부합하는가?

그래서 React의 구조도 지금까지 알아본 MVC를 통해 분류할 수 있을까 궁금해서 한 번 시도해보았다.

 

컴포넌트 상단에 state를 선언 -> 모델(Model)
컴포넌트 JSX 리턴부 -> 뷰(View)
여러 핸들러 및 이벤트 속성 -> 콘트롤러(Controller)

 

라고 분류할 수 있지 않을까 싶다. (순수 내 추측이다.)

그런데 useEffect같은 사이트 이펙트의 경우는 모델인거 같기도 하고, 콘트롤러인거 같기도 하여 조금 헷갈린다.

내가 모델로 여긴 state들이 바뀜을 감지하여 부수적인 조작을 하게 되는건데,

사용자가 직접 상호작용하는건 아니라 순수 콘트롤러라고 보기도 어렵고

그렇다고 useEffect 안에서 새로운 State를 정의한다던가 할수는 없기 때문에 순수 모델이라고 보기도 어려운거 같다.

 

그래서 React는 MVC패턴이 아니라고 한다. MVC를 개선하기 위해 만들어진 flux패턴에 가깝다고 한다.

리액트는 '컴포넌트 기반 아키텍처'라고 범용적으로 부를 수 있으며 flux패턴의 영향을 많이 받았다고 정리할 수 있을거 같다.

 

 

마무리

mvc구조를 개선하기 위해 flux가 나왔다고 들었는데, angular를 밀어내고 정상을 차지한 react를 생각해보면 실제 그런거 같다.

하여튼 다음엔 flux와 redux구조에 대해 알아보고 mvc에 비해 어떻게 좋아졌는지 알아봐야겠다.

그리고 이제 디자인 패턴에 대한 이해도 조금씩 쌓아야 할거 같은데 좋은 관련 서적 하나 찾아서 공부해봐야겠다는 생각도 든다.

 

그리고 리액트가 mvc 원칙에 구애받지 않는다 하더라도, 리액트 컴포넌트를 짤때도 mvc중 무엇에 속해있는가를 생각해보는 것도 괜찮은 방법인거 같다. 최근 지뢰찾기 만든 적이 있다. 지뢰찾기 맵 타일 하나하나에 비대한 컨트롤러 로직을 가지고 있게 짰는데, 전체 맵 컴포넌트에서만 핸들러를 가지고, 각각의 맵 타일에는 좌표값만 내려주고 혹시 클릭되면 좌표값을 다시 올려주는 형식으로 짰어야 할거 같다.

 

 

참고자료:

https://www.youtube.com/watch?v=ogaXW6KPc8I

https://velog.io/@seongwon97/MVC-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80

https://velog.io/@langoustine/%EC%97%AC%EA%B8%B0%EB%8F%84-MVC-%EC%A0%80%EA%B8%B0%EB%8F%84-MVC-MVC-%ED%8C%A8%ED%84%B4%EC%9D%B4-%EB%AD%90%EC%95%BC