MVVM 패턴과 AAC

Android 앱 개발을 하다보면, Activity 클래스에 모든 앱 동작 코드를 전부 집어넣는 경우가 많았다.
물론 동작에 있어 큰 문제는 없지만 체계적인 구조가 전혀 없어 추후에 유지 보수 또는 어떠한 곳에서 오류가 터지면 어딘지 찾는 것 또한 일이였는데..

실제로 회사에 다니며 작은 프로젝트를 맡아 진행을 했는데, 위의 방식으로 개발을 하다보면, 기능을 바꾸거나 추가할 때 어떤 부분을 수정해야 할지, 다 만들고 난 후 리팩토링 하자는 핑계로 넘어간적이 많았다.

이러한 코드가 계속쌓이면 스파게티 코드 가 된다.

MVC와 MVVM 차이점 🧐

MVC(Model / View / Controller)

Model
Model class로 비즈니스 로직에서의 알고리즘, 데이터 등의 기능 처리함

View
acticity_main.cml화면 부분 UI역할 담당

Controller
Activity부분에서 View에게는 화면 업데이트, Model에게는 데이터 갱신을 알린다.
View와 Model을 연결해주며 비즈니스 로직을 처리하기위해 많은일을 해야함

여튼 기존 만들어왔던 MVC패턴에 따라 Activity에 모든 코드를 다 넣으니 단점이 생긴다.

• 앱 동작이 많아질 수록 Activity 자체가 무거워진다.
• 스파게티 코드가 될 가능성이 높음.
  코드 복사/붙여넣기가 많아지게 되면서 코드 분리조차 되지않으면 코드가 아주 제대로 꼬여버립니다. 그렇기에 복잡도는 증가합니다. 다만, 이는 설계 단계에서 제대로해서 분리를 잘하면 어느정도 해소는 된다.
• Model과 View사이에 의존성 발생함. (서로간의 의존성 완전히 없앨 수 없음)
  즉, View의 UI 갱신을 위해 Model을 직/간접적으로 참조하므로 앱 자체가 커지고 로직이 복잡해질수록 유지보수가 힘들어진다.

💡 왜? MVC패턴의 동작이 아래와 같기 때문

1. Controller 가 사용자 동작을 받아들임 (텍스트 입력, 버튼 터치 등)
2. Controller 가 사용자의 동작에 따른 Model 업데이트를 요청함
3. Controller 가 Model 을 나타낼 View 를 선택함
4. View 는 Model 을 참조하여 UI 를 업데이트함

자연스레 View 와 Model 간의 의존성이 높아질 수 밖에 없다.
또한 Controller (Activity) 가 Model 과 View 사이에서 바쁘게 움직이고 있다.
혼자서 여기저기 요청을 보내야 하고 가운데에 껴서 고생하는 Controller 는 당연히 동작이 무거워진다.
따라서 코드 유지보수를 하다가 까딱했다간 UI 프레임 스킵 현상 및 메모리 릭 (Memory Leak)의 위험에 빠질지도 모름,,.

한마디로 MVC 패턴은 구현하기 쉬운 장점이 있는 반면, 기능 추가 및 변경에 있어 유지보수가 어렵다.

이러한 MVC패턴의 단점을 보완하고자 등장한 디자인 패턴이 바로 MVVM이다!
MVVM은 기존 MVC에서 Controller에게 많은 역할을 부여하기보다, 이 동작 자체를 분리하여
동작의 흐름을 더욱 체계적으로 만들어주고 유지보수를 편리하게 할 수 있도록 해주는 디자인 패턴

MVVM(View / ViewModel / Model)

View
Activity 역할을 담당하고 UI를 갱신하는 역할에만 충실!
사용자의 Action을 받음(텍스트입력, 버튼터치 등)
ViewModel의 데이터를 관찰(Observe)한다.
→ 데이터의 변화를 알아차리고 자동으로 화면을 갱신 할수 있음

ViewModel
View가 요청한 데이터를 Model로 요청
Model로부터 요청한 데이터를 받음

Model
ViewModel이 요청한 데이터를 반환
Room, Realm과 같은 DB사용이나 Retrofit을 통한 백엔드 API호출(네트워킹)이 보편적
Repository, DataBase부분으로 데이터 처리 역할

결국 View 가 필요로 하는 데이터는 ViewModel 이 쥐고 있고,
View 는 그것을 필요로 하기 때문에 ViewModel 이 쥐고 있는 데이터를 관찰 (Observing) 한다.

때문에 MVC 패턴과 다르게, View 가 DB 에 직접 접근하는 것이 아닌 UI 업데이트에만 집중한다.
또한 관찰하고 있는 만큼 데이터 변화에 더욱 능동적으로 움직이게 된다.

따라서 MVVM 패턴은 다음과 같은 장점을 가진다.

MVVM 장점

1. 뷰가 데이터를 실시간으로 관찰
-  LIveData (= Observable 패턴) 을 이용해 DB를 관찰하고 자동으로 UI를 갱신
- 직접 뷰를 바꾸어주는 번거로움을 없애고 데이터와 불일치할 확률이 줄어듦

2. 생명주기로부터 안전하여 메모리 릭을 방지할 수 있음
-  ViewModel을 통해 데이터를 참조하기 때문에 Activity / Fragment의 생명주기를 따르지 않는다. 
	→ 화면전환과 같이 액티비티가 파괴된 후 재구성이 되어도 뷰모델이 데이터를 홀드하고 있기 때문에 영향 X
- 뷰가 활성화 되어있을 경우에만 작동하기 때문에 불필요한 메모리 사용을 줄일 수 있음.

3. 기능별로 모듈화가되어 있어 역할을 분리 할 수 있고 유닛 테스트에 한결 용이
	→ 내장 DB를 통째로 바꾸고 싶다고 할 때, 뷰나 다른 코드에 깊게 종속되어 있지 않아, DB교체가 쉽다!
    	  뷰모델과 뷰가 1:N 연결이 가능!!
          따라서, 뷰모델에 하나의 메소드를 구현해두면, A 액티비티든 B 액티비티든 여러 뷰에서 호출하여, 재사용하기 편리

이러한 장점을 가지고 있는 MVVM 패턴은 잘만 사용한다면 훌륭한 앱을 만들 수 있다.
그렇지만 그만큼 구조가 복잡하다는 단점이 크게 다가오는데... 바로 진입장벽이 높음 😂.

그래도 MVVM 패턴을 간편하게 적용해볼 수 있게끔 구글에서 AAC 라는 것을 제공을 해준다.

AAC (Android Architecture Component)

참고 : https://velog.io/@jojo_devstory/안드로이드-아키텍쳐-패턴-MVC가-뭘까
https://velog.io/@haero_kim/Android-깔쌈하게-MVVM-패턴과-AAC-알아보기