[Android]안드로이드 애플리케이션 설계패턴

일반적으로 안드로이드 애플리케이션을 설계하는 패턴 중 가장 많이 사용되고 비교되는 패턴은 

MVC, MVP, MVVP 디자인 패턴이 있다.

 

1. MVC 디자인 패턴 

- 구조를 모델(Model), 뷰(View), 컨트롤러(Controller) 세가지 주요측면으로 분리한다. 

 1) 모델 

   : 비지니스로직과 데이터를 다루는 영역이다. 형식에 의존적이지 않고 사용자에게 보이지 않는 영역

   : 안드로이드에서는 데이터 베이스의 Entity를 담당하는 POJO 클래스를 포함한 SQLite, Room, Realm등이 해당

 2) 뷰 

    : 사용자에게 보여지는 UI 영역이며 안드로이드에서는 Activity, Fragment등이 속한다. 

 3) 컨트롤러 

    : 모델과 뷰에 의존한다. 상황에 따라 데이터를 불러와서 수정하고 전달하는 중간역할을 한다.  

    : MVC디자인 패턴에서 Activity와 Fragment는 뷰역할을 하지만 컨트롤러의 역할을 하기도 한다. 

 MVC 패턴의 장단점 

   장점 : 직관적이고 코드를파악하기 쉽다.

   단점 : 복잡도 증가, 차후 유지보수비가 증가할 수 있다. 뷰와 모델의 결합도가 높아 유닛테스트가 거의 불가능하다

 

2. MVP 디자인패턴 

MVC와 비슷하지만 Activity와 Fragment의 UI 그리고 비지니스 로직을 분리하는데 집중하므로 데이터의 흐름이 약간 다르다. 

MVP 디자인패턴은 Controller대신 Presenter라는 개념을 통해 UI코드와 비지니스로직을 분리하여 유닛테스트를 할 수 있다. 

Presenter와 View는 1:1 관계를 갖는다. 

 MVP패턴의 장단점

  장점 : View와 Model간의 의존성이 없고, UI와 비지니스 로직을 분리해 유닛테스트가 수월해진다. 

  단점 : 하지만 View가 늘어날때마다 Presenter도 같이 늘어나 클래스가 많아진다. 

3. MVVM 디자인패턴 

데이터 바인딩 및 LiveData 또는 RxJava같은 Observable타입을 이용하여 Presenter와 View사이에 강하게 연결되었던 점을 끊는데 집중

Presenter대신 ViewModel 이라는 구성요소를 사용하고 ViewModel은 View에 표현할 데이터를 Observable 타입으로 관리하며

데이터를 구독 요청하여 화면에 나타내는 것이 핵심이다. 그러므로 View와 ViewModel은 N:1의 관계가 있다. 

ViewModel이 View에 의존성을 갖지않고 느슨하게 연결되도록 Binding 라이브러리가 필수적으로 사용된다. 

 

구글에서 권장하는 안드로이드 설계 다이어그램

• 액티비티 또는 프래그 먼트는 단지 ViewModel 만을 참조한다. ViewModel만 참조하여 ViewModel에서 하위 계층의 의존성이 어떻게 변경되든 Activity 나 Fragment 는 관심이 없다.
• ViewModel은 Repository라는 저장소를 참조하고 이 저장소로부터 UI 컴포넌트가 화면을 구성하는 데 필요한 데이터를 불러온다. 데이터를 불러와 LiveData라는 데이터의 변화를 감지할 수 있는 형태로 관리한다.
• 저장소는 두가지 타입의 모델을 참조하는데, 한가지는 네트워크 연결이 필요없는 내부 모델이고, 다른 하나는 우리가 일반적으로 서버에서 데이터를 불러오는 네트워크가 필요한 원격 모델이다.
• ViewModel 이라는 것은 내부 데이터베이스만을 항상 참조하고, 클라이언트의 데이터 베이스와 서버의 데이터 베이스가 요청으로 비동기적으로 동기화 한다. 이렇게 되면 오프라인 또는 느린 네트워크 상황에서도 애플리케이션은 원활히 동작할 수 있고, 네트워크 상황이 종하지는 대로 다시 최신의 데이터로 UI 컴포넌트를 갱신할 수 있다.