Portfolio

디자인 패턴 MVC

MVC 패턴이 출현한 이유

기존에는 로직, 출력을 한 곳에서 처리하는 방식으로 진행되었습니다. 코딩하기에는 쉬웠지만 너무 많은 역할이 몰려있어서 유지보수면에서는 아니였습니다.

2001년 부터 웹 언어가 활성화 되어 동적인 페이지를 생성하기 위하여 ASP, JSP, PHP (웹 프레임워크들)의 서버 렌더링 기법이 나오기 시작하였고 내용을 보관하기 위한 데이터베이스가 중요해짐에 따라 view 와 model 을 구분하려는 노력이 나오게 되었습니다.

MVC?

Model, View, Controller로 이루어져있다.

Model은 상태, 상수, 변수 즉 데이터를 뜻합니다. 모델은 컨트롤러를 통해 내용을 갱신, 생성하여 뷰로 전달합니다.

view는 사용자가 확인할 수 있는 화면을 말합니다. 컨트롤러를 통해 뷰를 갱신하거나 모델에게서 정보를 받아 화면에 표시해주게 됩니다.

Controller는 사용자가 데이터를 변경하거나 요청하였을때 그 요청사항에 따라 모델에 접근하고 컨트롤러에서 바로 뷰를 갱신하는 경우도 있습니다.

하지만 책에서는 View와 model이 분리되어 재사용성과 확장성 면에서 용이하다고 설명되어있습니다. MDN과 책에서는 왜 다른 모습을 보여주는 것일까요?

오른쪽의 사진은 책에서 소개된 Cocoa MVC로 애플에서 Original MVC를 참조하고 변형한 형태입니다. 따라서 모든 사람에게 MVC가 같은 개념이 아닐 수 있습니다.

기존의 방식은 모델이 뷰를 알아야하고 뷰는 컨트롤러의 존재를 알아야 동작하므로 서로 얽혀서 의존성이 강해지게 됩니다. 이는 재사용성과 확장성면에서 좋지 않습니다.

또한 Cocoa 방식을 사용하여 model과 view의 의존성을 낮추는 것이 좋지만 다른 문제점으로는 애플리케이션이 복잡해질수록 컨트롤러의 비중이 매우 커지고 모델과 뷰의 관계가 복잡해지는 단점이 있습니다.

일단 궁금한점 하나를 해결했으니 다음으로는 MVC 패턴의 예를 찾아보겠습니다.

책에서는 리액트가 MVC 패턴의 예라고 나와있네요!

리액트는 사실상 View만 신경쓰는 라이브러리입니다. 또한 React는 Flux 패턴을 따릅니다.(단방향 바인딩)

물론 디자인 패턴은 그 개념을 적용하여 사용하는데 의미가 있습니다. 하지만 적절한 예로는 PHP, Angular를 예로 들수 있습니다.

이러한 오류가 발생한 이유는 백엔드의 시점에서의 MVC와 프론트엔드의 MVC에 차이가 있기 때문이라고 생각합니다.

백엔드 MVC의 View는 만들어지는 결과값 같은 개념이였다면 프론트엔드에서는 이벤트의 발생지가 되기 때문입니다.

MVC vs SPA

웹의 초창기에, PHP, JSP 같은 웹 프레임워크들의 MVC 구조는 클라이언트가 폼이나 링크를 통해 업데이트를 요청하거나 업데이트된 뷰를 받아 다시 브라우저에 표시하기 위해 대부분 서버 사이드에서 구현되었습니다. 반면, 요즘에는, 클라이언트 사이드 데이터 저장소의 출현과 필요에 따라 페이지의 일부만 업데이트를 허용하는 XMLHttpRequest 를 포함해 더 많은 로직이 클라이언트 사이드에 추가되었습니다. 프론트엔드의 SPA에서 MVC 패턴을 생각해보면 여러개의 뷰와 여러개의 모델 사이에 하나의 컨트롤러를 두게 되는데요. 이는 이전에 설명한 컨트롤러가 너무 비대해지는 현상이 일어나거나 아래 사진과 같이 데이터의 흐름이 양방향으로 이뤄지면 복잡도가 더 증가하고 디버깅, 가독성이 떨어지기 때문에 MVC는 작은 앱에 더 적합하다고 말할 수 있습니다.