🏗️ MVC MVP MVVM

-> MVVM 패턴을 선택한 이유

💡 MVC - 요소 간 의존성이 강하다는 단점이 존재함. view 를 수정할 경우 controller 를, controller 를 수정할 경우 
model 까지 수정해야 하는 경우가 생길 수 있음. 또한 view 와 model 이 controller 를 중심으로 복잡하게 연결될 수 있기 때문에 
controller 가 비대해지는 경우가 발생할 수 있어 선택하지 않음.

MVP -  view 하나를 만들 때마다 presenter를 모두 하나씩 만들어줘야 하며, view - presenter 사이에 매우 높은 의존성. 
그렇기 때문에 view 의 이벤트에 따라 model 의 상태 변경이 필요한 경우 변경 후 다시 view 에 적용하기 위해 presenter 가 해야하는 일이 늘어남.

→ 위와 같은 이유로 나머지 패턴이 아닌 MVVM 패턴을 선택함.

MVC

---

Model + View + Controllor

• Model
  • UI상태, 비즈니스 로직, 데이터를 처리함
  • 데이터의 상태가 변경되면 일반적으로 view 에 알려줌.
• View
  • 유저에게 보여지는 UI 를 나타내는 역할을 하며, model 로부터 표시할 데이터를 받음.
  • view 는 controller 를 모름
• Controller
  • 유저 입력에 따라 model 이나 view 를 변화시킴
    • 유저의 입력이 controller 에 들어오면 controller 는 model 을 업데이트하고 이 데이터를 나타낼 view 를 선택하게 됨.
    • model 에서 업데이트 한 값을 view 로 보내거나, 데이터 변경이 아닌 보여지는 방식이 달라지는 경우 (ex. 기존 데이터 정렬) controller 에서 처리해서 view 로 보내줌.
  • Controller 와 View 는 1:n 구조

MVP

---

View + Presenter + Model

UI (View) 와 비지니스 로직 (Model) 을 분리하고 서로 간의 상호작용에 Presenter를 사용하면서 둘의 의존성을 최소화.

• Model
  • 앱 전반에서 쓰이는 데이터 처리
  • 다른 두 요소에 의존적이지 않음.
• View
  • 유저에게 보여지는 UI 를 나타내는 역할
  • Model에서 처리된 데이터를 Presenter에서 받아 유저에게 보여주기 때문에 Presenter에 매우 의존적.
• Presenter
  • view에서 input 이 들어오면 이를 model 로 가공하여 view 에 전달해줌.
  • 화면 그 자체는 아니지만, 보여줄 것을 관리해야 하기 때문에 view와 presenter는 1:1 관계.

MVVM

---

View + ViewModel + Model

• Model
  • 사용되는 데이터와 데이터를 처리하는 부분
• view
  • 사용자의 액션을 받음.
  • 유저에게 보여지는 UI 를 나타내는 역할
  • viewModel의 데이터를 관찰해서 (live data, observe) UI 를 갱신. 데이터의 변화를 알아차리고 자동으로 화면을 갱신할 수 있다.
  • view 는 viewmodel와 data binding 을 통해 화면을 나타냄
• viewModel
  • view 를 그리는 것에는 관여하지 않고 view 를 나타내주기 위한 데이터 처리를 담당.
  • view가 요청한 데이터를 model로 요청하고 model 로부터 요청한 데이터를 받음.
  • viewModel 과 view 의 관계는 1:1 이 아니어도 되며, 1:N 도 가능함.
  • presenter 와 다르게 재사용이 가능함.