Topic = Architecture와 Architecture Pattern들의 개념
Why - Architecture 의 필요성
Architecture
Architecture란, 단어 뜻 그대로 건축 방식, 설계 방식으로 프로젝트 구조의 설계도이다. Architecture는 앱의 전반적인 구조와 흐름의 방향을 제시한다. 이는 일관된 코드작성을 통해 복잡성을 줄이고 유지보수성을 높일 수 있으며 테스트가 용이하고, 코드 재사용성과 확장성을 촉진하는 등 앱 전반적인 품질 향상에 큰 요건이 된다.
Architecture의 적용은 프로젝트 초기에 아키텍처 선택, 작성해야 할 코드의 양의 증가 등으로 오히려 복잡성을 키울 수 있지만, 특정 지점이 지나면 NoDesign보다 좋은 생산성을 보여줄 수 있다.
Architecture Pattern
Architecture는 개개인이 구상해서 만들 수 있지만, 몇몇 아키텍처는 Pattern화 되어 MVC, MVP, MVVM, MVI 등으로 여러 프로젝트에서 사용하는 Architecture Pattern으로 사용된다. 해당 Architecture Pattern을 사용함으로 내 프로젝트에 새로운 사람이 참여하거나, 내가 다른 프로젝트에 참여하는 상황에서도 코드의 흐름을 파악하고 진행하기가 수월해짐과 동시에 개발자 간의 커뮤니케이션 비용을 줄일 수 있다.
앱 개발에 사용하는 거의 모든 Architecture Pattern은 객체 지향 프로그래밍을 기본적으로 포함하고 있기 때문에 객체 지향 프로그래밍에 대한 별도의 고민이 줄어들고, Architecture Pattern 자체가 여러 사람이 사용해보면서 많은 이점을 갖는 증명된 Architecture들이 Pattern화 된 것임으로 확립된 모범사례를 통해 일반적으로 할 수 있는 설계의 실수를 줄일 수 있다.
Architecture 핵심
- 컴포턴트별로 역할을 명확하게 나누고 의존 관계를 분명하게 하는 것
- 앱의 생명 주기 문제에 영향을 받지 않도록 모델에서 UI 도출
MVC
MVC 패턴은 Model - View - Controller 세 가지의 측면으로 관심사를 분리하여 안드로이드 개발에 적용하는 패턴으로 웹 개발에서도 사용되는 패턴이지만, Android는 내부 API에 종속적이라서 웹에서 사용하는 MVC 방식과는 조금 다른 형태를 띈다.
Model
- 앱에서 사용하는 데이터, 상태, 비즈니스 로직을 포함한다. 데이터는 판매중인 아이템, 상품의 가격 등과 같은 데이터를 캡슐화하고 데이터의 조작 및 검색을 위한 로직을 제공한다.
- 일반적으로 Model에 데이터 베이스와 데이터 베이스 구조, 그리고 API Service과 같은 네트워크 요청 등의 데이터 소스가 포함된다
View
- Android MVC에서 View는 XML 기반의 Layout으로 모델의 데이터를 사용자에게 표시하는 사용자 인터페이스( UI )요소에 해당하는데, 사용자와 상호작용에서 데이터표시, 사용자 입력 수신, 처리를 위해 해당 입력을 컨트롤러에게 전달하는 역할까지만 수행한다.
Controller
- Android MVC의 Controller는 Activity, Fragment에서 View의 사용자 상호작용을 전달받아 인식한 뒤 Model을 업데이트 하거나, Model의 변경된 정보를 전달 받아 UI를 갱신하는 것과 같이 View와 Model간의 데이터 흐름을 제어하며 앱의 수명주기를 관리한다.
MVC Pattern의 장단점
이러한 특징을 가진 MVC는 class 하나로 처리가 가능한 구조로 정리가 쉬운 작은 프로젝트에서는 구현하기 쉽고, 코드 자체를 쉽게 파악할 수 있는 장점이 있지만 프로젝트 규모가 어느정도 커지기만 해도 코드를 파악하기가 어려워 진다.
웹에서는 View와 Controller가 분리되어 있지만, Android의 경우, Activity와 Fragment가 View와 Controller 둘 다 가지고 있다. 때문에 Activity와 Fragment에 많은 코드가 쌓여 비대화 문제가 발생하며 View와 Controller가 강하게 결합되어 있어 Model에 의존성이 강해 테스트가 어렵다. 이러한 문제를 해결하기 위해 MVP Pattern이 생겨났다.
MVP
MVC Pattern의 경우 Activity, Fragment에서 Controller의 역할과 View 역할을 동시에 하기 때문에 UI 로직이 포함되어 생기는 문제들을 해결하기 위해 UI 로직과 비즈니스 로직을 분리하는데 집중하는 Pattern이다.
Model, View
- MVC에서 작성해둔 Model, View와 동일한 개념이다.
Presenter
- Model과 View를 분리 시킴과 동시에 View와 Model을 연결해주는 역할을 하며 MVC처럼 View와 결합되어 있지 않고, 사용자의 입력을 받아와 이벤트를 전달하는 View class와 Interface로 Presenter class를 만들어 별도로 나누어 Presenter와 View를 구분할 수 있다.
- View와 Presenter는 1:1의 관계이다. 이는 View에 해당하는 Num1 Activity에는 Num1 Presenter가 필요하다는 것을 의미한다. 앱 규모가 클 경우 여러개의 View - Presenter 쌍이 존재할 수 있는데 이때 각 View - Presenter의 쌍은 서로 다른 부분을 담당하며, 모듈화 된 형태로 앱을 구성하게 된다.
- MVP Pattern은 MVC의 문제를 어느정도 해결해 직관적이면서 간단한 코드 작성이 가능하며, 테스트를 MVC에 비해 비교적 쉽게 할 수 있게 되었지만 여전히 View와 Presenter의 사이에 의존성이 있기 때문에 유지보수성의 측면에서의 문제가 있었다. MVVM도 이러한 MVP의 문제점을 해결하기 위해 나왔다.
MVVM
MVP의 View와 Presenter 사이의 강한 의존 관계를 해결하기 위해 Presenter대신 ViewModel을 사용하고 View는 사용자의 입력에 따른 이벤트를 ViewModel을 통해 지정해준다. MVVM을 학습할 때 가장 기억에 남던 특징은 MVVM의 각 요소들은 단방향의 관계로 View는 ViewModel을 알지만 ViewModel은 View를 모르고, ViewModel은 Model을 알지만 Model은 ViewModel을 알지 못한다는 것이다 이로 인해 구성요소간의 의존성은 있지만 목적이 있는 의존성으로 최소화 하여야 한다.
MVVM은 SOLID 구조를 지향하며 각 요소간의 관심사 분리를 촉진하고 각 구성요소의 역할을 명확하게 정의하여 앱 전반적인 모듈성과 테스트 용이성을 갖출 수 있다.
LiveData와 ViewModel을 사용하는 예제는 별도로 게시글에서 정리.
[TIL] Kotlin ViewModel / LiveData / Observer Pattern
[오늘 배운 내용] -1- ViewModel ViewModel을 왜 사용하는지 구성 변경에 대한 데이터 보존 Activity나 Fragment는 화면 변경 등과 같은 이유로 구성 변경이 이루어지면 onCreate부터 재생성이 된다. Activity나 Fr
junes-daily.tistory.com
AAC ViewModel은 MVVM의 요소인 ViewModel과 다르다?
근데 여기서 한가지 문제가 생긴다. 여러 의견들을 듣고 정리하기 위해 다양한 글을 찾다보니 AAC ViewModel 이 MVVM의 구성요소에 해당하는 ViewModel과는 조금 다르다는 글을 보게 되었고, 몇몇 글에서는 Activity, Fragment에서의 Observe를 사용하는 것이 MVVM에 의도에 적합하지 않은 코드라는 것이며, DataBinding을 사용해야 한다 라는 내용이다.
기존의 웹 개발에서의 MVVM과 AAC 라이브러리의 ViewModel이 제공되기 전에는 개발자가 별도로 생명주기 관리를 해주어야 했다, AAC는 이러한 별도의 생명주기 관리를 AAC의 ViewModel을 제공함으로써 안드로이드 컴포넌트 ( Activity, Fragment )의 생명주기와 연동하여 생명주기 관리 기능을 제공하는데, 일부 글 들에서는 이러한 생명주기를 관리하는 기능으로 인해 MVVM의 ViewModel이 AAC에서 제공하는 ViewModel과 다르다고 주장하는 것이다. 하지만 앱 개발에 있어서 MVC 또한 기존의 View와 Controller가 분리되어져 있는 웹 개발 개념의 MVC와 다른 것 처럼 AAC의 ViewModel을 통한 MVVM 패턴 구현이 MVVM이 지켜지지 않는다고 할 수는 없을 것 같다.
🌟디자인 패턴은 클래스 라이브러리 자체가 아니다. 클래스 라이브 러리가 디자인 패턴의 '의도' 를 구현하는 것이다.
- AAC ViewModel은 Model 과 View 사이에 비즈니스 로직을 분리하여 의존성을 낮추고 유지보수성, 재사용성을 높기기 위한 의도로 구현되었다.
- 의도에 반하는 주장 - XML을 사용하게 된다면, XML과 View ( Activity or Fragment )가 ViewBinding을 사용하건, DataBinding을 사용하건 XML View와 Activty or Fragment 간의 의존성이기 때문에 View와 비즈니스 로직을 분리하는 ViewModel을 사용할 때 DataBinding을 사용하여 XML과 Activity or Fragment ( View ) 의 의존성을 관리하라고 강제 하는 것은, 디자인 패턴의 의도를 중요시 하는 것보다, 기존에 사용하던 정립된 방식( DataBinidng을 사용하여 의존성을 관리하는 방식 ) 을 하나의 라이브러리라고 치면 해당 라이브러리 자체가 디자인 패턴이라고 주장하는 것과 비슷하게 느껴진다.
[ A. 오늘 복습한 내용 / B. 다음에 학습할 내용 ]
A. LiveData와 ViewModel에 대해서 추가적으로 학습. 기존에는 MVVM과 Google Docs 에서 접하는 Architecture Pattern이 동일한 패턴인 줄 알았으나, 차이점이 존재하는 것을 알게 되었다.
B. Gof Design Pattern. Facade 패턴과 같은 디자인 패턴에 대한 내용에 대해서 추가로 학습할 예정
B. Clean Architecture에 대한 자세한 개념 및 AAC ViewModel과 MVVM의 ViewModel 의 확실한 차이와 무엇이 맞는지에 대한 추가 학습
[느낀 점]
1. 얕게 학습하면 디테일한 부분을 가져가기가 어렵다.
2. 다른 사람에게 뭔가를 설명하기전에 정확한 내용인지 한번 더 확인해보자.
3. 어쨌든 중요한 건 구성요소간의 의존관계를 명확하게 하여 관심사를 분리하는 것이 모든 것의 목적
[Reference]
// MVVM vs AAC
https://nuritech.tistory.com/7
https://velog.io/@spdlqjfire/Android-AAC-ViewModel-vs.-MVVM-ViewModel
// MVC, MVP, MVI
https://thdev.tech/androiddev/2016/10/23/Android-MVC-Architecture/
// Architecture Pattern
https://developer.android.com/jetpack/guide?hl=ko
https://martinfowler.com/bliki/DesignStaminaHypothesis.html
https://6mini.github.io/software%20architecture%20pattern/2022/11/07/architecture/
