03. MVC 패턴

대부분의 일들이 그러하지만 개발자는 특히 혼자서 처음부터 끝까지 모든 프로젝트를 담당해서 업무를 진행하지 않는다.

그러므로 개발자는 다양한 환경에서 다양한 사람들과 협업을 하는 일이 잦은데 그럴때 마다 매번 새로운 규격과 환경에 적응해서 일을 하기란 쉽지 않다. 모든 회사, 모든 동료가 같은 규격을 가지고 협업하면 얼마나 편할까?

이러한 고민을 해결해주기 위해 MVC 패턴이 사용된다.

---

MVC 패턴의 등장 배경

 위에서 간략하게 설명했듯이 MVC 패턴은 다른 사람들과 협업하기에 용이하도록 만든 일종의 규칙? 혹은 규약이라고 할 수 있다. MVC 패턴을 검색해보면 디자인패턴이라는 말이 자주 등장하는데 이는 쉽게 이해해보자면 '유지보수 하기 쉽게 다같이 통일된 형식으로 개발하자' 이다. 반대로 얘기해보면 MVC 패턴을 적용하지 않을 때 서버에 어떤 에러가 발생하면 우리는 여러 사람이 개발한 여러 API와 그 속에서 동작하는 수많은 함수들 중 에러가 난 부분이 어디인지 일일히 살펴봐서 찾아야한다. 이는 막말로 혼자서 처음부터 끝까지 전부다 코드를 짠 본인도 바로 찾으라하면 해맬것이다. 하물며 여럿이서 함께 작성한 코드는 어떻겠는가 그저 지옥.. 그래서 우리는 유지보수측면에서 유용하고 효율적이게 코드를 분류하고 로직을 짜야하는데 이때 MVC 패턴에 맞게 API와 함수등을 분류해준다.

 

그래서 MVC 패턴이 뭔데??

서로간의 화살표 방향을 유의깊게 보자!

• Model

 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분을 담당한다. 즉, 위의 그림에서 보듯 사용자가 입력정보를 주면 그 데이터에 맞추어 데이터를 처리하고 저장한다. 화살표를 통해 알 수 있듯이 model 부분은 오직 controller와 정보를 주고받으며 controller에서 주는 명령에 맞추어 동작하며 결과를 보내준다. 이전에 미니프로젝트 하며 Rest API 연습했을때 schema를 적어주었던 부분이 이와 비슷한것 같다.

 

• controller

 위의 데이터플로우를 대충만 봐도 이놈이 가장 중추적인 역할을 한다는게 보인다. controller는 그 이름에 맞게 모든 동작을 컨트롤하는 녀석이다. 즉, 화면에서 입력받은 정보를 받아 model에서 처리할 데이터는 보내주거나 필요한 부분을 가져와서 함수와 api를 실행시킨다. 한마디로 Rest API에서 주로 POST, GET, PATCH 등등을 실행했던 부분이다. 그러나 그 API를 좀더 가독성 좋게 만들어 주기위해서 class로 객체를 할당해주고 거기서 필요한 부분을 호출해서 동작한다. 

 

• view

 말그대로 화면에 보여지는 브라우저를 의미한다. 옛날옛적에는 프론트와 백엔드의 구분이 명확하지 않아 백엔드에서 지금의 프론트엔드가 개발하는 화면 UI부분을 담당했었다고 한다. 그때 사용되는 파일이 바로 이 view 부분인데 사실상 지금은 많이 사용하지 않는 듯 하다.. 기본적으로 view에서 유저가 입력한 정보들을 controller로 보내주고 가공된 데이터를 화면에 보여주는 역할을 한다. 그 외의 추가적인 view 부분의 역할이 있으면 추가하도록 해야겠다!

 

MVC 패턴의 장단점

• 장점

1.  서로다른 환경속에서 살아온 이들도 함께 웃으며 작업 가능한 규칙적인 구조
2.  어디서 에러 터졌는지 어디부분을 유지보수 해야 하는지 비교적 수월하게 찾을 수 있어 유지보수에 있어서 비용이 절감
3.  코드의 재사용성이 향상 ( 필요한 함수를 만들어 놓고 여기저기서 호출해서 쓰면되기 때문)

• 단점

1.  유지보수 할때는 쉽지만 그만큼 설계 단계에서 좀더 복잡하고 규격을 고려해야하기 때문에 어려움
2.  당연히 구현하기까지 개발 시간이 비교적 오래걸림
3.  model과 view의 의존성이 높다 --> 사실 직접 체감한 부분이 아니라서 잘 모르겠지만 추후에 많은양의 데이터를 다룰때 이 부분이 문제가 된다고 한다.