MVVM 클린 아키텍쳐
캠프 과정을 진행하며 MVVM구조에 대해 알게되고 사용해보면서 어느정도 익숙해지자, 튜터님께서 MVVM 클린 아키텍쳐에 대해서 알아보기를 추천했다. 그래서 같은 수강생을 조르고 졸라 기본적인 MVVM아키텍쳐 패턴을 알 수 있었다.
(MVVM에 대해서는 다음에 상세하게 적어봐야겠다.)
기존의 동작방식
API를 통해 데이터를 받아와 처리하는 과정에서 클린 아키텍쳐구조를 사용하는 과정과, 사용했을때의 장점을 알아보았다.
우선 기존 방식을 살펴보면 MVVM구조를 사용하고는 있지만 Retrofit을 통해 받아온 데이터 형태(DTO: Data Transper Object)를 그대로 사용하는 구조로 구현을 했었다.
이러한 구조로 데이터를 사용할 경우 기존에 사용하던 API를 교체해야하는 경우가 생기게되면 해당 API를 통해 받아온 데이터(DTO)를 절달받는 모든 view model의 값들을 수정해야하는 일이 발생하게 된다.
이러한 일을 방지해 재사용성을 높이기 위해 Entity나 Repository Interface를 사용해Data와 View의 의존성을 낮춰, 추후에 어느 한부분에서 변경이 일어나더라도 상호 영향을 미치지 않도록 분리해주는 작업을 한다.
변경후 MVVM
Remote DB -> Repository
기존의 방식과 같이 Retrofit Interface에 요청이 들어올 경우 Remote DB에서 Retrofit라이브러리를 통해 데이터를 받아온 뒤 해당 데이터를 통해 DTO를 생성해 주었다.
Retrofit을 통해 데이터를 받아온 API별로 Repository를 구성해준다.
이때 Repository를 인터페이스로 선언하고 해당 Repository를 구현한 Repository Impl로 데이터들을 관리해준다.
이는 API별로 데이터를 받아오는 로직이 다르기때문에 추후에 해당 API에 이상이 생기더라도 다른 API를 통해 원하는 정보를 받아오기 수월하도록 하기 위함이다.
Repository인터페이스에서는 필요한 메서드들을 정의해 두고, Repository Impl에서 해당 메서드들을 구현하게 되면 어떤 API를 사용하든 같은 기능을 하는 코드를 만들 수 있게 된다.
Repository -> ViewModel
API를 통해 Remote DB에서 받아온 데이터들은 Repository에서 Entity로 컨버팅한 후 각각의 view model로 전달된다.
Entity
받아온 데이터들을 view model에서 필요한 형태로 컨버팅한 데이터 객체이다.
API를 통해 전달받은 데이터들은 같은 유형의 데이터(비디오, 이미지, 글 등)이더라도, 각각의 방식대로 저장되어있기 때문에 서로 다른 model형태를 가진다.
그렇기 때문에 어떤 형태의 model모델이 전달되더라도 View에서 바로 사용이 가능하도록 Entity를 만들어 컨버팅 하게되면 View와 Data간의 의존성을 최소화 시킬 수 있다.
view model에서 받아온 Entity들을 각각 view에 전달해야하는 형태로 컨버팅해준다.
오늘은 어땠나요?
저를 밤샘 아티스트라고 불러주세요
