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

MVC 패턴

💡 애플리케이션 구조를 Model, View, Controller 세개의 측면으로 관심사를 분리한다.

개발을 배울 때 가장 먼저 배운 패턴이다.

그렇기 때문에 이해하기도 가장 쉬웠다고 생각한다.

 

안드로이드에서 activity, fragment 가 view 역할을 한다.

동시에 controller 의 역할을 하기도 한다.

 

장점

• 직관적이다.

위에서 이해하기 쉬웠던 이유가 바로 이 장점 때문이 아닐까?

• 코드를 파악하기 쉽다.

단점

• (안드로이드에서는) 위에서 말했듯 activity, fragment 가 뷰와 컨트롤러의 역할을 겸하다 보니 앱의 규모가 커지면 수천줄의 코드가 작성되어 유지보수가 힘들어진다.
• 컨트롤러는 뷰와 모델에 의존적이고, 뷰는 모델에 의존적이기 때문에 결합도가 높아 유닛 테스트가 거의 불가능하다.

 

MVP 패턴

💡 컨트롤러 대신 Presenter 가 존재한다. UI 코드와 비즈니스 로직을 분리하기 위함이다.

Presenter 는 view 와 model 의 인스턴스를 가진다.

그리고 이 둘을 연결하는 역할을 하기 때문에 presenter 와 view 는 1:1 관계를 가진다.

 

 

장점

• view 와 model 간의 의존성이 없다.
• UI 와 비즈니스 로직을 분리했기 때문에 유닛테스트가 수월하다.

단점

• 1:1 관계이므로 view 가 늘어나면 presenter 도 늘어난다. (재사용 할 수 없음)

 

MVVM 패턴

💡 데이터 바인딩 및 LiveData 또는 RxJava 와 같은 Observable 타입을 이용해 Presenter 대신
viewModel 이라는 구성요소를 사용
💡 컨트롤러처럼 파싱된 데이터를 응답하지 않는다.
💡 변경된 데이터를 감지해 UI를 동기화 한다.

 

viewModel 은 view 에 표현할 데이터를 Observable 타입으로 관리,

view 들이 viewModel 에 데이터를 구독 요청하여 화면에 나타내는 것이 핵심

따라서 viewModel 과 view 는 1:N 관계

 

viewModel 이 view 에 대한 의존성을 갖지 않고 느슨하게 연결되도록

DataBinding 라이브러리가 필수적으로 사용된다.

 

 

 

 

다음 글에서는 MVVM 을 구현해보는 시간을 가져보려고 합니다.

잘못된 부분이 있으면 지적해주세요!

읽어주셔서 감사합니다.

---

References

아래 도서를 참고하여 작성 되었습니다.

아키텍처를 알아야 앱 개발이 보인다