[안드로이드] - Android Design pattern (MVC, MVP, MVVM)

MVC

 

Flow(동작방법)

1. 사용자의 Action 이 Controller 에 들어온다.
2. Controller 는 사용자의 Action 을 확인하고, Model 을 업데이트한다.
3. Controller 는 Model 을 나타내줄 View 를 선택한다.
4. View 는 Model 을 이용하여 화면을 나타낸다.

 

특징

• Controller 는 여러 개의 View 를 선택할 수 있는 1:N 구조이다.
• Controller 는 View 를 선택할 뿐 직접 업데이트 하지 않는다. (즉, View 는 Controller 를 모른다.)
• View 와 Model 을 완벽하게 분리하고, Model 테스트가 용이하다.

 

단점

• Controller 가 Android API 에 종속되어 테스트가 어렵다.
• View 를 변경하면 Controller 도 변경해야 한다.
• 많은 코드들이 Controller 에 집중되면 성능이 저하되고 유지보수가 어려워진다.

 

 

MVP

 

Flow(동작방법)

1. 사용자의 Action 이 View 를 통해 들어온다.
2. View 는 data 를 Presenter 에게 요청한다.
3. Presenter 는 Model 에게 data 를 요청 받는다
4. Model 은 Presenter 에게 요청 받은 data 를 반환한다.
5. Presenter 는 View 에게 data 를 반환한다.

 

특징

• Presenter 는 View 와 Model 의 인스턴스를 가지고 있어 둘을 연결하는 역할을 한다.
• Presenter 와 View 는 1:1 관계이다.
• 단순 Interface 이기 때문에 테스트가 용이하고 모듈화 / 유연성 문제가 해결되었다.

 

단점

• View 와 Presenter 간의 의존성이 높다.
• Android API 를 참조해서는 안된다.(권장)
• Controller 와 같이 코드가 집중되면 성능이 저하되고 유지보수가 어려워진다.

 

 

MVVM

 

Flow(동작방법)

• 사용자의 Action 들은 View 를 통해 들어오게 된다.
• Command Pattern 으로 ViewModel 에 Action 을 전달한다.
• ViewModel 은 Model 에게 data 를 요청한다.
• ViewModel 은 응답받은 data 를 가공하여 저장한다.
• View 는 ViewModel 과 Data Binding 하여 화면을 나타낸다.

 

특징

• Command Pattern 과 Data Binding 을 사용하여 구현한다.
• View 와 Model 사이의 의존성이 없다.
• View 와 ViewModel 사이의 의존성도 없다.
• 모든 부분이 독립적이므로 모듈화가 가능하다.

 

단점

• ViewModel 설계가 어렵다.
• View 가 변수와 표현식 모두에 Binding 될 수 있으므로, 갈수록 Presentation logic 이 늘어나 XML 이 방대해진다.