[안드로이드] 디자인 패턴 겉핥기 (MVC, MVP, MVVM)

디자인 패턴 알아보기

MVC

• Model + View + Controller 의 구조
• Model : 애플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
• View : 사용자에서 보여지는 UI
• Controller : 사용자의 입력을 받고 처리하는 부분
• 동작
  1. 사용자의 액션이 controller 로 들어온다.
  2. controller 는 사용자의 액션을 인하고 Model 을 업데이트 한다.
  3. Controller는 Model 을 나타내줄 View를 선택한다.
  4. View는 Model을 화면에 나타낸다.
• MVC 에서 View 가 업데이트 되는 방법
  • View가 Model을 이용해 직접 업데이트 한다.
  • Model에서 View에게 Notify 하여 업데이트 한다.
  • View가 Polling으로 주기적으로 Model의 변경을 감지해 업데이트 한다.
• Controller는 여러개의 View를 선택할 수 있는 구조 (View는 Controller를 알지 못한다.)Controller는 View를 선택할 뿐 직접 업데이트 하지 않는다.
• 단점 : View와 Model간의 의존성이 높다.

MVP

• Model + View + Presenter 의 구조
• Presenter : View에서 요청한 정보로 Model을 가공해 View에 전달해 주는 부분으로, view와 Model을 붙여주는 접착제 역할을 한다.
• 동작
  1. 사용자의 액션이 View를 통해 들어온다.
  2. View는 Model의 데이터를 Presenter에게 요청한다.
  3. Presenter는 Model에게 데이터를 요청한다.
  4. Model은 Presenter에서 요청받은 데이터를 응답한다.
  5. Presenter는 View에게 데이터를 응답한다.
  6. View는 Presenter가 응답한 데이터로 화면을 나타낸다.
• Presenter와 View는 1:1 관계이다.
• View와 Model간의 의존성을 없앴다. (Presenter를 통해서만 데이터를 전달받기 때눙)
• 단점 : View와 Presenter 사이의 의존성이 높다. 애플리케이션이 복잡할수록 View와 Presenter 사이의 의존성이 강해진다.

MVVM

• Model + View + ViewModel 의 구조
• ViewModel : View를 표현하기 위해 만든 View를 위한 Model로, View를 나태내기 위한 데이터를 처리하는 부분이다.
• 동작
  1. 사용자의 액션은 View를 통해 들어온다.
  2. Command 패턴으로 ViewModel에 액션을 전달한다.
  3. ViewModel은 Model에게 데이터를 요청한다.
  4. Model은 ViewModel에게 요청받은 데이터를 응답한다.
  5. ViewModel은 응답받은 데이터를 가공해 저장한다.
  6. View는 ViewModel과 DataBinding을 하여 화면을 나타낸다.
• Command패턴과 DataBinding 두가지 패턴을 사용하여 구현되었다.
  • Command 패턴 : 요청을 객체의 형태로 캡슐화 해 사용자가 보낸 요청을 나중에 이용할 수 있도록 필요한 정보를 저장, 로깅, 취소할 수 있게 하는 패턴이다.
    • command, reciever, invoker(발동자), client의 구성으로 이루어져있다.
  • DataBinding : 데이터를 provider와 consumer 간에 bind 하고 synchronize 한다.
• View와 Model 사이의 의존성이 없다. 각각은 독립적이기 때문에 모듈화해 개발할 수 있다.
• 단점 : ViewModel의 설계가 쉽지 않다.Respository란?
• MVVM에서 Respository는 데이터(Retrofit 등)을 가져오는 클래스들과 1:n 매칭이 가능한 유일한 클래스입니다.
• ViewModel 이 View에 사용되는 데이터를 요청하면 Repository는 요청한 데이터를 로컬 / 네트워크에서 찾아 이를 전달해 준다.
• Repository를 인터페이스로 만들고 구현체를 만들어 사용하는 곳에서 특정 구현에 의존하지 않도록 할 수 있다.
  
• viewmodel이 직접 remote 든 local 데이터의 데이터를 가져온다면, 비즈니스 로직에 집중해야 할 viewmodel 클래스가 초기화 코드 등까지 가지게 된다.
• repository 가 db 초기화 및 작업을 맡아주고, viewmodel 은 이를 상속해서 사용하여 vm -> repo -> db 의 구조가 됩니다.

  open class MainViewModels : ViewModel(){
    val mRealm: Realm by lazy {
        Realm.getDefaultInstance()
    }
    fun getAllStudentData(): LiveData<RealmResults<Student>> {
        return mRealm.studentDao().getAllstudents()
    }
    override fun onCleared() {
        mRealm.close()
        super.onCleared()
    }
  }

• ->

  class TestRepository {
     private val mRealm: Realm by lazy {
         Realm.getDefaultInstance()
     }
     fun getAllStudentData(): LiveData<RealmResults<Student>> {
         return mRealm.studentDao().getAllstudents()
     }
  }
  ...
  open class MainViewModels: ViewModel() {
     private val mRepository: TestRepository by lazy {
         TestRepository()
     }
     fun getAllStudents(): LiveData<RealmResults<Student>> {
         return mRepository.getAllStudentData()
     }
  }

참고 링크

• MVC, MVP, MVVM 비교
• MVVM AAC LiveData
• AAC를 사용해 MVVM Pattern을 구현한 안드로이드 앱 만들기
• Repository