[Architecture]MVC(Model View Controller)

어플리케이션을 model, view, controller 세 가지 역할로 구분하여 개발하는 소프트웨어 개발 방법론

사용자가 입력을 담당하는 View를 통해 요청을 보내면 해당 요청을 Controller가 받고,
Controller는 Model을 통해 데이터를 가져오고,
해당 데이터를 바탕으로 출력을 담당하는 View를 제어해서 사용자에게 전달한다.

컴포넌트화 해서 역할을 구분지어 놓는 느낌인 것 같다.

Model

어플리케이션이 무엇을 할 것인지 정의한다. 내부 비즈니스 로직을 처리하기 위한 역할
즉, 데이터 저장소(ex. DB)와 연동하여 사용자가 입력한 데이터나 사용자에게 출력할 데이터를 다룬다.

View

화면에 무엇을 보여주기 위한 역할
즉, 모델이 처리한 데이터나 그 작업 결과를 가지고 사용자에게 출력할 화면을 만든다. 만든 화면은 웹 브라우저가 출력한다.

Controller

Model과 View 사이에 있는 컴포넌트
Model이 데이터를 어떻게 처리할지 알려주는 역할

클라이언트의 요청을 받으면 해당 요청에 대한 실제 업무를 수행하는 Model을 호출한다.
클라이언트가 보낸 데이터가 있다면, 모델을 호출할 때 전달하기 쉽게 적절히 가공한다.
Model이 업무 수행을 완료하면 그 결과를 가지고 화면을 생성하도록 View에 전달한다.

즉, 클라이언트의 요청에 대해 Model과 View를 결정하여 전달하는 일종의 조정자로서의 일을 한다.
∴ 요청에 따라 로직 처리를 위한 model을 호출하고 서버에서 처리된 데이터를 포함한 view를 리턴한다.

참고:
https://tecoble.techcourse.co.kr/post/2021-04-26-mvc/
https://medium.com/@jang.wangsu/%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-mvc-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80-1d74fac6e256

controller를 사용하는 이유

대규모 서비스로 갈수록 처리해야 할 서비스들이 많아지므로 이를 하나의 클래스에서 몰아서 처리할 게 아니라 controller라는 중간 제어자 역할을 만들어 A요청에 대한 것은 A-controller가 맡아 필요한 로직 처리를 위한 서비스를 호출하게 한다.

MVC 역할에 따라 설계하여 개발하면 개발 비용이나 유지보수 비용이 대폭 줄어든다.

+++ 23.01.06 내용 추가
참고: [프론트엔드에서 MVC보다 더 많이 쓰이는 패턴은?] https://www.youtube.com/watch?v=Y5vOfv67h8A

컨트롤러에서 model과 view를 생성해서 view에 model을 전달해줘서 의존성 주입

백엔드에서 MVC는 매우 유명하고 많이 사용됨

FE에서는?

최근 프론트엔드는 복잡한 view가 많아짐 (페이지 전환없이 여러 가지 렌더링을 하는 SPA가 많아짐)

FE는 view 그 자체인데, 온갖 이벤트가 발생하는 main이자 controller와 같은 일을 할 수밖에 없는 곳.

1. view의 변경으로 model을 바꿔야 한다.

ex. 사용자 입력 값

2. model의 변경으로 view를 바꿔야 한다.

ex. 서버로부터 받은 데이터

결국 양방향에 대한 문제로 복잡도 상승 + view가 매우 많음 + 잦은 리렌더링 + view간의 계층 처리 필요(tree 구조) => 문제 발생 가능성 상승

controller가 매우 비대해진다.

=> 복잡한 view, model 관계 단순화, view 계층 처리로 쉽고 효율적인 DOM 처리 필요

-> 요즘 FE에서 실제 사용되는 기술은
데이터 바인딩, MVVM, Flux Architecture(React에서 사용)

• 1. Data binding

  Svelte 같은 프레임워크 사용
  

• 2. MVVM

  Vue.js 등의 프레임워크
  

• 3. React Flux Architecture

  
  그림의 반시계 방향의 흐름으로 제어하면서 만드는 원리

왼쪽 예시는 Redux, 오른쪽 예시는 Recoil

영상 결론: