MVVM의 등장
웹 개발의 패러다임
MVC의 한계
- 비지니스 로직과 화면 개발을 분리하는것이 필요하여 model과 view를 분리하였다.
- model과 view의 결합에 있어서 controller의 중요도와 복잡성이 높아졌다.
- controller의 중요도가 올라가며 유지보수와 확장성에 어려움이 생겼다.
서버의 MVC는 잘 되던데?
- 서버단 아키텍쳐의 controller는 상대적으로 템플릿 방식을 사용하여 덜 복잡하게 구현된다.
- 클라이언트에서는 화면의 변화를 그려내기 위해서는 복잡한 DOM 조작을 해야했다.
- 그러나 웹서버에서는 템플릿에 데이터를 바인딩하고 html 을 그려내는 방식이다.
- 직접적인 DOM 조작이 아닌 템플릿 방식이 훨씬 간단하고 선언적이다.
- 그래서 클라이언트단에도 적용하기 위해 나온것이 MVVM이다.
클라이언트에서 템플릿 방식?
우리는 처음에 html과 js 를 분리하여 작성했다. 그런데 html 에다가 onclick과 같은 js기능을 직접넣어서 하는 방식이 마냥 틀린것일까? DOM을 조작사지 않고 html에 직접 기능을 작성하는 템플릿 방식으로 할 수 있지 않을까? 라고 해서 나온것이다.
no selector, no event, no Dom조작
MVVM
controller 에서 viewModel로
- mvc 패턴에서 컨트롤러를 수동으로 스크립트 작성하기에는 규모가 너무 커짐
- 그런데 컨트롤러의 수행과제는 다 거기서 거기더라.. 1.M->V:데이터변경에 따른 화면 변화 / 2. V->M: 사용자 이벤트에 따른 모델변화
- 그럼 자주 쓰이는 패턴을 미리 만들어둬서 자동화를 시키고 스크립트 작성을 줄인다음 템플릿으로 작성해보자
어떻게 controller 에서 viewModel로 바꾸나?
- 선언적 데이터 바인딩 : 자주 쓰이는 컨트롤러를 미리 만들어 두고 html에 작성해서 사용하자
MVVM패턴이란
Model - View - ViewModel
개발 방법은 ?
- 처음 보여질 화면을 템플릿으로 작성한다.
- 화면이 변해야 하는 곳에 데이터 바인딩을 걸어둔다. 2-1. 변경 감자기 가능한 모델을 만들어서 연결 2-2. DOM이 어떻게 변경되어야하는지 알려준다. 2-3. 자동으로 모델이 변경되면 해당 html이 변경된다.
- 이벤트를 연동 3-1. 사용자가 이벤트에 따라 데이터를 변경한다. 3-2. 변경된 데이터에 따라 자동으로 화면이 변경된다.
즉 데이터를 작성하고 알아서 그리도록 선언적으로 작성하는 것이다.
결국 프론트 엔드는 화면의 변화이지만, 데이터의 변경을 통해 화면을 제어할 수 있게 됐다.
