[Flutter] MVC, MVVM

 

MVC

Model, View, Controller로 구성된 뷰 아키텍처.

컨트롤러가 많은 것들을 담당하는 형태이다.

• 모델(Entity, DB)의 데이터를 가져오고 업데이트
• 모델 값 변화가 일어난 경우, 새로 뷰 그려주기

MVC의 단점

• 컨트롤러가 담당하는게 너무 많다.
• 컨트롤러가 모델에 대한 컨트롤과 뷰에 대한 컨트롤을 모두 담당하고 있기 때문에, 모델에 변화가 생기면 뷰 까지 영향이 미쳐, 뷰의 수정이 필요함. → 유지보수가 어려움.
• 모델의 설계를 아무리 잘 해도, 개발을 지속하면서 모델을 수정하는 일은 불가피하므로 유지보수의 측면에서 영향을 받을 수 밖에 없다.

MVVM

Model, View, ViewModel 로 구성된 뷰 아키텍처. MVC 아키텍처의 단점들을 보완하고자 제시되었다.

모델과 뷰 사이에서 뷰모델이 중간다리 역할을 하는 형태이다. 컨트롤러로서의 역할을 줄여 복잡성을 낮추었다.

• 모델에서 각 뷰가 필요로 하는 데이터만 가져와서 뷰모델을 구성한다.
• 모델을 수정하더라도, 뷰에는 영향을 주지 않고 뷰모델만 수정해주면 된다. → 뷰와 모델의 의존성 ↓ (뷰는 뷰모델의 데이터에만 의존하므로 뷰모델이 모델의 데이터에 맞춰주기만 하면 된다.)
• 화면 갱신을 컨트롤러가 아닌 뷰가 담당한다. 뷰모델의 데이터 변화를 감지해 뷰가 알아서 필요한 위젯만 새로 그리는 방식을 사용한다.

 

뷰와 모델 간의 의존성을 떨어뜨리기 위해 각 뷰가 필요로 하는 데이터만 따로 빼내어 저장해두는게 뷰모델이였다니… 맞는 말인 것 같다. 모델의 데이터 구조가 수정되었을 때, 뷰가 뷰모델이 가지고 있는 모델에 직접 접근한다면 이건 MVC의 단점을 그대로 가지고 있는 것이니깐.

이 부분은 이번에 MVVM을 찾아보면서 처음 알았던 것 같다. 오… 메모...

 

이걸 코드로 짧게 표현해보면 아래와 같다. 중간 변수 단계를 하나 더 넣어서 영향을 줄인다고 생각하면 될 것 같다.

class MVCController {
  Model model
  functions...
}

class MVCView {
  Text(MVCController.model.content)
}

[ 만약 Model의 content가 body로 바뀐다면 ]

class MVCController {
  Model model
    functions... // content를 쓰는 함수들에서 Error 발생
}

class MVCView {
  Text(MVCController.model.content) // Error 발생
}

=> 컨트롤러와 뷰를 모두 수정해주어야 한다.

class MVVMController {
  Model model
  String content = model.content
  functions...
}

class MVVMView {
  Text(MVVMController.content)
}

[ 만약 Model의 content가 body로 바뀐다면 ]

class MVVMController {
  Model model
  String content = model.content  // Error 발생
  functions...  // content를 쓰는 함수들에서 Error 발생
}

class MVVMView {
  Text(MVVMController.content)  // 에러 없음!
}

=> 뷰모델만 수정해주면 된다.