MVC Pattern

Model
상태(state)를 다룬다.
상태는 화면의 렌더링에 영향을 주는 변수이다. 서버로부터 받은 데이터를 가공하는 역할을 수행할 수도 있다.
모델은 데이터베이스에 있는 데이터를 가져와 다른 객체에 전달해 줍니다. 또는 외부 객체로부터 데이터를 받아서 DB에 넣어줍니다.

View
모델에서 받아온 데이터로 화면을 관리합니다. 사용자가 입력한 데이터를 처리하고, 유저가 생성한 입력 이벤트 데이터를 다른 객체에 전달하는 역할을 합니다. 즉 화면의 구성(렌더링)을 담당한다.

Controller
모델과 뷰를 연결시켜주는 역할로, 모델에서 받아온 데이터를 뷰에 전달합니다. 또는 뷰에서 사용자가 입력한 데이터를 모델로 보내줍니다.
View와 Model 사이의 인터페이스 역할, 비즈니스 로직과 이벤트를 처리하는 역할을 한다.

Component 는 Controller 역할을 하는 클래스이고, model과 view 인스턴스를 필드로 갖고 있다.
생성 시점에 model과 view 객체를 받아 컴포넌트에 바인딩한다.

MVC 패턴 왜 사용할까?
MVC 패턴에 대한 여러 글을 읽어봤지만, 결국 '유지보수의 편리성'이라는 하나의 결론으로 수렴합니다. 최초 설계를 꼼꼼하게 진행한 시스템이라도 유지보수가 발생하기 시작하면 각 기능간의 결합도(coupling)가 높아지는 경우가 발생합니다. 이는 최초 설계 이념을 정했던 사람들의 부재 혹은 비즈니스 요건 변경으로 인해 필연적으로 발생하는 것 같습니다. 결합도가 높아진 시스템은 유지보수 작업 시 다른 비즈니스 로직에 영향을 미치게 되므로 사소한 코드의 변경이 의도치 않은 버그를 유발할 수 있습니다.

선배 개발자들은 이런 문제점을 해결하기 위해 UI 시스템의 핵심 컴포넌트를 모델, 뷰, 컨트롤러로 나누고 각 컴포넌트가 자신의 수행 결과를 다른 컴포넌트에게 전달하는 프로그래밍 방식을 만들었습니다. MVC 패턴을 가진 시스템의 각 컴포넌트는 자신이 맡은 역할만 수행한 후 다른 컴포넌트로 결과만 넘겨주면 되기 때문에 시스템 결합도를 낮출 수 있습니다. 유지보수 시에도 특정 컴포넌트만 수정하면 되기 때문에 보다 쉽게 시스템 변경이 가능합니다. (화면의 변경은 only 뷰, 데이터나 비즈니스 요건이 변경은 only 모델, 뷰와 모델 변경에 따른 일부 컨트롤러 변경)

알기 쉽게 MVC 검색을 해보다
한가지 예제를 보고 이해가 되어서 첨부해본다

✔️ 위의 개념을 WEB에 적용 시!
사용자가 웹사이트에 접속 (Users)
Controller는 사용자가 요청한 웹페이지를 서비스하기 위해서 모델을 호출 (Manipulates)
Model은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후 그 결과를 Return
Controller는 Model이 리턴한 결과를 View에 반영 (Updates)
데이터가 반영된 View는 사용자에게 보여짐 (Sees)
이렇게 순서대로 읽어보니 이해가 딱 갔다!

reference

https://velog.io/@imnotmoon/MVC-Pattern-vanila-JavaScript
https://mber.tistory.com/58
https://junilhwang.github.io/TIL/Javascript/Design/Vanilla-JS-Component/
https://asfirstalways.tistory.com/231
https://junhyunny.github.io/information/design-pattern/mvc-pattern/