1. 안드로이드 애플리케이션 설계 원칙
앱 제작 과정에서 액티비티 또는 프래그먼트 같은 UI 컴포넌트에 Context, View, 데이터, 시스템 이벤트 등을 쉽게 참조할 수 있다는 이유로 많은 코드를 작성하는 경우 단점이 존재합니다.
- 예외 사항들에 대응이 힘듭니다.
- 거대해진 코드로 인한 가독성 저하
- 유지보수가 어렵다
그러므로 액티비티와 프래그먼트의 클래스 의존성은 최소화하는 것이 좋으며, 가장 중요한 원칙은 관심사 분리로, SOLID 원칙과도 많은 부분이 부합되며, 이를 통해 클래스 간의 의존성을 낮추어 모듈화 시킨다는 의미입니다.
즉, 관심사 분리를 통해 모듈화를 성공적으로 마치게되면, 애플리케이션의 설계, 배포, 유지보수 측면에서 이점이 생기고, 코드 또한 단순화됩니다.
*모듈 : 다른 모듈로부터 독립적이며 영역에 따라 다른 역할을 한다는 의미
2. 권장하는 애플리케이션 설계
애플리케이션 설계 시, 구글에서 권장하는 관심사 분리에 대해 알아보겠습니다.
액티비티 또는 프래그먼트는 ViewModel만을 참조하며, ViewModel에서 하위 계층의 의존성이 어떻게 변경되든, 액티비티나 프래그먼트는 관심이 없습니다.
ViewModel은 Repository라는 저장소를 참조하여 저장소로부터 UI 컴포넌트가 화면을 구성하는데 필요한 데이터를 불러온 후 LiveData라는 데이터의 변화를 감지할 수 있는 형태로 관리하며, 변경이 감지되면 UI 컴포넌트의 바인딩된 뷰에 표시합니다.
| 저장소가 참조하는 두 가지 타입의 모델 | ||
| 네트워크 연결이 필요없는 내부 모델 | 일반적으로 DB를 지징하며, DBMS는 프레임워크에 포함된 SQLite와 SQLite 기반의 Room 또는 범용적으로 많이 사용되는 Realm 등이 있습니다. | |
| 네트워크가 필요한 원격 모델 | 일반적으로 Http 통신이 될 수 있으며, OkHttp 또는 Retrofit과 같은 라이브러리가 주로 서버와 통신에 사용됩니다. | |
또한 일반적으로 사용자 경험을 증대시키도록 서버에서 얻은 데이터는 내부 데이터베이스에 저장하여 불러옵니다.
이유는 클라이언트의 데이터베이스와 서버의 데이터베이스가 요청으로 비동기적으로 동기화하면, 네트워크 상황이 좋지않아도 애플리케이션은 원활히 동작할 수 있고, 네트워크 상황이 좋아지면 다시 최신의 데이터로 UI 컴포넌트를 갱신할 수 있습니다.
3. 안드로이드 애플리케이션 설계 패턴
안드로이드 애플리케이션을 설계하는 패턴에는 여러 가지가 있지만, 가장 많이 사용되는 것을 뽑으라면 MVC, MVP, MVVM 디자인 패턴입니다.
3-1. MVC 디자인 패턴
MVC 디자인 패턴은 애플리케이션 구조를 Model, View, Controller 세 가지로 관심사를 분리합니다. MVC 패턴은 안드로이드 플랫폼의 등장 초기에 애플리케이션을 개발할 때, 어떻게 애플리케이션을 설계해야 하나에 관한 질문들이 제기될 때, 당시 스프링을 비롯한 웹에서 사용하는 가장 유명한 UI 패턴이 MVC라, 많은 개발자들이 안드로이드에 MVC 패턴을 적용해 왔습니다.
3-1-1. Model
애플리케이션의 비즈니스 로직과 데이터를 독립적인 영역입니다. 표현되는 형식에 의존적이지 않으며, 사용자에게 보이지 않아 어떻게 보일지에 대한 신경을 쓰지 않아도 됩니다.
일반적으로 비즈니스 데이터는 DBMS에 의해 관리되고 몇몇 함수를 통해 데이터를 제공하거나 입력, 수정 등을 하는 역할을 합니다.
안드로이드에서는 데이터베이스의 Entity를 담당하는 POJO 클래스를 포함한 SQLite, Room, Realm 등이 될 수 있습니다.
3-1-2. View
사용자에게 표현되는 영역으로, 모델로부터 얻은 데이터를 뷰에서 표현합니다.
안드로이드에서는 액티비티, 프래그먼트가 뷰의 역할을 합니다.
3-1-3. Controller
모델과 뷰에 의존하며, 뷰로부터 입력, 이벤트를 받아 모델 / 뷰를 변경할 수 있습니다.
컨트롤러는 사용자로부터 받은 입력을 데이터 모델로 전달하고 데이터베이스에 입력하며, 모델이 변경되면 모델은 등록된 뷰에 변경을 알리고 뷰는 사용자에게 변경된 모델을 표시합니다.
안드로이드에서는 액티비티, 프래그먼트가 뷰의 역할도 하면서 컨트롤러의 역할을 하기도 합니다.
3-1-4. MVC 디자인 패턴 장단점
| MVC 디자인 패턴 장단점 |
|||
| 장점 | 직관적인 코드 / 단순한 구조 / 짧은 개발기간(규모가 작은 경우) | ||
| 단점 | 스파게티 코드 / 유지보수의 어려움 / 유닛 테스트의 어려움(규모가 큰 경우) | ||
3-2. MVP 디자인 패턴
MVC 디자인 패턴과 유사한 점이 많지만, MVP 디자인 패턴은 MVC 디자인 패턴에서 액티비티와 프래그먼트의 UI 그리고 비즈니스 로직을 분리하는데 집중한 디자인 패턴입니다.
3-2-1. Model
애플리케이션의 비즈니스 로직과 데이터를 다루는 독립적인 영역입니다. 표현되는 형식에 의존적이지 않으며, 사용자에게 보이지 않아 어떻게 보일지에 대한 신경을 쓰지 않아도 됩니다.
일반적으로 비즈니스 데이터는 DBMS에 의해 관리되고 몇몇 함수를 통해 데이터를 제공하거나 입력, 수정 등을 하는 역할을 합니다.
안드로이드에서는 데이터베이스의 Entity를 담당하는 POJO 클래스를 포함한 SQLite, Room, Realm 등이 될 수 있습니다.
3-2-2. View
사용자에게 표현되는 영역으로, 모델에서 처리된 데이터를 Presenter를 통해 얻어 데이터를 뷰에서 표현하며, 사용자의 이벤트와 생명주기의 상태 변경을 주시하며 Presenter에 전달하는 역할을 합니다.
안드로이드에서는 액티비티, 프래그먼트가 뷰의 역할을 합니다.
3-1-3. Presenter
모델과 뷰 사이의 매개체라는 점에서 MVC 디자인 패턴의 Controller와 유사하지만 직접 연결이 아닌 인터페이스를 통해 상호작용합니다.
Presenter는 사용자로부터 받은 입력을 데이터 모델로 전달하고 데이터베이스에 입력하며, 모델의 데이터만을 뷰에게 전달하는 역할만 담당하고 어떻게 보여줄지는 뷰가 담당합니다.
안드로이드에서는 Interface와 Interface를 구현하는 Class가 Presenter의 역할을 합니다.
3-1-4. MVP 디자인 패턴 장단점
| MVP 디자인 패턴 장단점 |
|||
| 장점 | View와 Model 간의 의존성이 없음 / UI와 비즈니스 로직의 분리를 통해 수월한 유닛 테스트 | ||
| 단점 | 애플리케이션에 기능이 추가될수록 거대해지는 Presenter / View와 Presenter 간의 의존성이 높고, 1:1 관계를 유지하기위해 Presenter를 재사용할 수 없어 View가 늘어날 때마다 Presenter도 같이 늘어나는 많아지는 Class | ||
3-3. MVVM 디자인 패턴
MVP 디자인 패턴에서는 View와 Presenter가 1:1 관계로 강하게 결합되지만, MVVM 디자인 패턴은 데이터 바인딩 및 LiveData 또는 RxJava와 같은 Observable 타입을 이용해 MVP 디자인 패턴에서 Presenter와 View 사이의 강한 결합도를 끊는데 집중한 디자인 패턴입니다.
MVVM 디자인 패턴에선 Presenter 대신 ViewModel을 사용하며, ViewModel은 View에 표현할 데이터를 Observable 타입으로 관리하고 View들이 ViewModel에 데이터를 구독 요청하여 화면에 표시할 수 있어, ViewModel과 View는 1:N 관계를 가집니다.
MVVM 디자인 패턴에선, ViewModel이 View에 대한 의존성을 갖지 않고 느슨하게 연결되도록, DataBinding 라이브러리가 필수적으로 사용됩니다.
즉, 양방향 databinding으로 사용자 이벤트나 rxJava, LiveData 같은 Observable 타입 데이터를 xml에서 활용하도록 코드를 작성하여 databinding이 View와 ViewModel 간에 매개체 역할을 하고 의존성을 최소화시키는 겁니다.
MVVM과 Android DataBinding
MVVM에서의 가장 큰 특징은 옵저빙 이다. 리액티브 프로그래밍에서 말하는 옵저버 패턴과 같은 의미. View가 ViewModel이 가진 데이터를 옵저빙 하고 있다가 ViewModel의 데이터가 변경되면 자동으로 Vi
umbum.dev
오늘은 클린 코드를 설계할 수 있는 구글에서 권장하는 애플리케이션 설계와 안드로이드 애플리케이션 설계에서 자주 사용되는 MVC, MVP, MVVM에 대한 개념을 알아봤습니다.
주로 MVVM을 사용했지만, 다음 시간에는 각 디자인 패턴에 대한 예제를 작성해보겠습니다.
'Android' 카테고리의 다른 글
| DI(의존성 주입) 프레임워크 : Dagger2란 (0) | 2021.05.08 |
|---|---|
| Dependency Injection : 의존성 주입 (0) | 2021.05.08 |
| 안드로이드 개념) WorkManager를 사용한 백그라운드 작업 - kotlin (0) | 2021.05.02 |
| [Android] 비동기 처리를 위한 방법 (0) | 2021.04.30 |
| [Android] Intent (명시적, 암시적) (0) | 2021.04.16 |
