MVC
Model
- 데이터(ex: DB data)와 연관된 작업을 수행하는 부분
- Model에 의해 관리되는 변수 = 사용자에 의해 추가/수정/삭제되는 데이터들
View
- Model로부터 값을 가져와서 표 같은 부분에 렌더해줌.
Controller
- 사용자의 이벤트를 통해 데이터의 변경이 필요한 경우 처리 로직을 수행한 뒤 Model에 통보.
- Model이 View에 변경된 상태를 알리면 View가 최신화를 수행함.
process
- controller가 model에게 데이터를 요청한다.
- 가져온 데이터를 가공한 뒤 이를 토대로 view가 화면에 렌더링한다.
- 사용자가 특정 행위를 수행해서 데이터 변경을 요청한다.
- controller가 action을 확인한 뒤 로직을 수행하여 model을 업데이트한다.
- model에 연결된 observer가 view에게 변경사항을 업데이트하도록 한다.
MVP
Model
- DB, REST API등 데이터와 관련된 비즈니스 로직(컴퓨터 프로그램의 규칙에 따라 데이터를 생성·표시·저장·변경하는 부분)을 처리
View
- Activity, Fragment와 같은 사용자 인터페이스 역할. view에서 발생하는 이벤트를 presenter에게 위임 ⇒ 액티비티가 뷰 인터페이스를 구현해서 Presenter에서 코드를 만들 인터페이스를 갖도록 하면 됨.
Presenter
- View에서 이벤트를 받아와 데이터를 가공하고 Model에 전달 후, 가공한 데이터를 View에 전달. 한마디로 view ↔ model 사이의 자료 전달 역할.
MVVM
Model
- DB, REST API등 데이터와 관련된 비즈니스 로직을 처리
View
- MVP에서는 프레젠터가 뷰의 메소드를 호출했지만 MVVM에서는 data binding을 통해 뷰 스스로 View Model의 상태변화를 감지함
- View에 action이 들어오면 VM에서 해당 action을 처리하게 한 뒤 VM에서 비즈니스 로직이 처리됨
ViewModel
- view에서 사용되는 데이터와 명령을 구성.
내가 MVVM으로 구현했던 방식
Fragment와 ViewPager와 이중으로 RecyclerView를 사용할 필요가 있었다.
MVVM을 적용하기 전까진 RecyclerView Adapter에 거의 모든 로직과 View set등이 몰려있어서
MVC에서의 Controller화 되는 현상이 발생했다.
물론 로직 상 문제는 없지만 추후 유지보수할 때 과거의 나와의 치열한 싸움을 벌여야 할 것 같아... 또한 Adapter의 코드가 외적으로도 매우 더러워 졌기에
ViewModel 클래스를 따로 생성하여 Adapter의 메소드들을 하나 둘 옮겨줬다.
원래의 MVVM이라면 VM에서의 데이터 변화를 감지해 자동으로 View가 update되어야 하지만...
정상 작동하지 않아 아직 그 작업은 적용해놓지 않았다.
때문에 ViewModel에 binding 객체를 넘겨주어 직접 set해주고있다.
아직까진 ViewModel이라고 하기에는 민망하고 그냥 adapter의 로직들을
옮겨놓은 수준에 불과한 것 같긴 하지만 개인적으로는 훨씬 깔끔해진것 같아
마음에 드는 중이다.
And dev