MVC 패턴

모델-뷰-컨트롤러(model–view–controller, MVC)는 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다. 이 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다. MVC에서 모델은 애플리케이션의 정보(데이터)를 나타내며, 뷰는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.

• 위키백과

MVC 패턴이란??

• M(Model/ 모델)

  서비스에 필요한 모든 데이터는 모델에서 정의됩니다.
  오로지 Model 레이어에 정의된 데이터베이스 schema를 통해서만 데이터베이스에 접근해 CRUD 로직을 처리할 수 있습니다.

• V(View/ 뷰)

  클라이언트와 상호작용이 일어나는 것을 의미합니다.
  화면에 보여주기 위한 역할을 하는 것 입니다.

• C(Controller / 컨트롤러)

  유저의 요청을 처리해서 응답하는 부분이라고 할 수 있습니다.
  Controller는 Model과 소통하게 됩니다.

MVC 패턴의 장점

• 각 로직을 분리하여 오류의 발견, 코드 수정을 하기 좋게 해준다
• 동시적인 개발을 가능하게 해준다( 각 역활이 나뉘어져 있어, 동시 다발적인 개발이 가능하다.)
• 유지보수 비용을 절감할 수 있다
• 테스트-주도개발 (각각의 레이어, 그리고 그 레이어 속에 속한 각각의 모듈을 테스트 하기 좋다.)

MVC 패턴의 단점

• 다양한 모듈들로 구성되기 때문에 복잡도가 높아진다
• 설계시간이 오래 걸리고 숙련된 개발자가 필요하다

MVC 패턴의 한계

• 어플리케이션이 커지고 기능 및 화면, 데이터 등이 다양해지면 MVC 패턴은 Controller를 중심으로 여러 개의 Model과 View가 형성하게 됩니다. 이럴 경우 Controller에 다수의 Model과 View가 연결되어버리고, 뚱뚱한 Controller, Massice ViewContoller 꼴이 만들어져버립니다.
• 이럴 경우 MVC 패턴 코드 자체가 너무 복잡해지고 커져버려서, 새 기능(혹은 데이터) 등을 추가할 때마다 에러가 발생될 수도 있으며 가독성이나 효율성도 떨어지게 됩니다. 처음에는 단순했던 controller가 점점 많은 것들을 처리하게 되면서 꼬여버리는 형태가 되는 것입니다.
• 즉, 뷰와 모델이 의존성을 띄게 되어 분리할 수도 없고, 여러 side-effect를 불러와 예상치 못한 에러 등이 발생될 수도 있습니다. 이를 보완하기 위해서 MVP, MVVM, Flux, Redux 등등와 같은 다른 패턴 및 라이브러리들이 존재합니다.

참고자료

• https://velog.io/@kjhxxxx/Node.js-MVC-Pattern
• https://velog.io/@jinukix/Node.js-MVC-%EB%AA%A8%EB%93%88%ED%99%94
• https://foamless.tistory.com/456