MVC 패턴

• 애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중할 수 있다.

• 재사용성과 확장성이 용이하다.

• 하지만 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다.

• 뷰와 모델이 긴밀하게 상호작용해서 뷰와 모델의 의존성이 높다.

• 대표적인 라이브러리로 React가 있다.

모델

• 상수, 변수, 데이터베이스
• 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신한다.

뷰

• 화면 요소
• 모델이 가진 정보를 따로 저장하지 않고, 화면에 표시되는 정보만 가지고 있다.
• 변경이 일어나면 컨트롤러에 이를 전달한다.

컨트롤러

• 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할
• 이벤트나 생명주기 등 메인 로직을 담당
• 모델이나 뷰의 변경을 확인해서 대처하는 역할
• Controller는 여러개의 View를 선택할 수 있는 1:n 구조다.
• Controller는 View를 선택할 뿐 직접 업데이트 하지 않는다. (View는 Controller를 알지 못한다.)

동작 순서

1. 사용자의 Input과 같은 action들이 Controller에 들어온다.
2. Controller는 사용자의 Action를 확인하고, Model을 업데이트한다.
3. Controller는 Model을 나타내줄 View를 선택합니다.
4. View는 Model을 이용하여 화면을 나타냅니다.

리액트

• 대표적인 특징으로 불변성(immutable)이 있다. 예를 들어 state는 setState를 통해서만 수정이 가능하고, props를 기반으로 만들어지는 컴포넌트를 사용한다.

• 단방향 바인딩이고, 라이브러리이기 때문에 프레임워크보다 자유도가 높다.

• 가상 DOM을 통해 실제 DOM을 조작하는 것을 추상화해서 성능을 높였다.

MVP 패턴

• MVC 패턴과 유사하나 컨트롤러가 아닌 프레젠터(presenter)로 교체된 패턴이다.

• 뷰와 프레젠터는 일대일 관계이기 때문에 MVC 패턴보다 더 강한 결합을 지닌 패턴이다.

• 뷰와 모델 사이의 의존성은 해결되었지만, 뷰와 프레젠터 사이의 의존성은 여전히 높다.

동작 순서

1. 사용자의 Action들은 View를 통해 들어오게 됩니다.
2. View는 데이터를 Presenter에 요청합니다.
3. Presenter는 Model에게 데이터를 요청합니다.
4. Model은 Presenter에서 요청받은 데이터를 응답합니다.
5. Presenter는 View에게 데이터를 응답합니다.
6. View는 Presenter가 응답한 데이터를 이용하여 화면을 나타냅니다.

MVVM 패턴

• MVC의 컨트롤러 대신 뷰모델(view model)로 바뀐 패턴이다.

• 양방향 데이터 바인딩

• 데이터 바인딩 : 화면에 보이는 데이터와 서버 데이터를 일치시키는 기법

• 뷰와 모델 사이의 의존성이 없고 뷰와 뷰모델 사이에도 의존성이 없다.

• 각 요소들이 독립성을 유지하기에 모듈화하여 개발하기 쉽고, 유닛 단위로 테스트하기 편하다.

동작 순서

1. 사용자의 Action이 뷰를 통해 들어옴
2. 뷰에서 Action이 들어오면, 뷰모델에 Action을 전달
3. 뷰모델은 모델에게 데이터를 전달
4. 모델은 뷰모델에게 요청 받은 데이터를 응답
5. 뷰모델은 응답 받은 데이터를 가공하여 저장
6. 뷰는 뷰모델과 데이터바인딩하여 화면을 나타냄

Vue.js

• 함수를 사용하지 않고 값 대입만으로도 변수가 변경되며 양방향 바인딩이 가능하다.