Repository 패턴에 대해서 정리해 보겠습니다

MVVM 혹은 MVP에 대해서 알고 계신다면 Repository에 대해서 알고 계실텐데요.

오늘은 이 Repository패턴에 대해서 정리해 보겠습니다.

1. Repository 패턴과 MVVM

Repository의 역할을 이해하기 위해서,

MVVM에서의 Repository의 역할을 보며 정리해 보겠습니다.

 

아래의 표는 구글 공식사이트에 존재하는 도표인데요.

이것을 보면 Repository가 ViewModel과 Room이라고 하는 DB나 Retrofit사이에 있습니다.

ViewModel이 Activity나 Fragment에 보여주려고 하는 데이터를 

Repository에 요청하면 Repository가 요청한 데이터를 받아서 보내 준다는 것 입니다.

도표에서 느낄 수 있듯이 분업화가 매우 확실합니다.

데이터 모델과 비즈니스 로직이 분리되어 있는 가운데,

그 사이에 interface로서 Repository가 존재하고 있네요.

 

위에서도 언급하였지만,

Repository는 ViewModel이 요청하는 데이터를

Room이나 Retrofit으로부터 가져와 전달해 줍니다.

이렇게 해주면, ViewModel은 누구한테 가져온 데이터인지는 신경쓰지 않아도 되겠지요.

자신의 비즈니스 로직만 집중하면 됩니다.

Realm인지 Room인지 Retrofit을 통한 http서비스를 통해서인지, 혹은 SharedPreference인지

ViewModel은 전혀 신경쓰지 않아도 된는 것이지요.

이런 것들은 Repository가 처리해 주니까요.

 

2. Repository클래스

코드를 수정해 보면서 정리해 보도록 하겠습니다.

아래 코드는 repository클래스가 없이,

ViewModel에서 직접 Realm데이터 베이스의 Dao클래스를 이용해서,

데이터를 가져오고 있는데요.

비즈니스 로직에 집중해야 할 ViewModel클래스가,

로컬 db인 Realm의 초기화코드까지 가지고 있는 상태입니다.

 

 

 

이제 Repository클래스를 추가해 보도록 하겠습니다.

 

ViewModel에서 realm에 직접 접근했던 것 들을,

아래와 같이 Repository클래스를 만들어서 하나의 레이어를 추가하게 됩니다.

대신, ViewModel은 이제 DB초기화 작업 같은 일은 하지 않아도 되는 것이지요.

 

 

이제 repository클래스가 생겼으니, 이를 이용하도록 ViewModel의 기존 코드를 수정하도록 하겠습니다.

 

이렇게 해서 ViewModel -> DB Dao클래스로 연결 되던 것이,

ViewModel -> Repository -> DB Dao로 하나의 레이어가 추가되었구요.

수정한 ViewModel을 activity에서 Databinding시켜주거나 observer를 붙여서 활용해 주면 되겠습니다.

 

물론 실제 프로덕션 레벨에서는 이렇게 간단하다기 보다는

위에서 언급한데로, 웹서비스, SQLite, SharedPreference 등등 많은 것들과 연결되어 있을 것이고,

그럴수록 Repository클래스의 의미가 살아나는 것이겠지요.

 

3. 정리

Repository패턴을 사용한다면, 관리할 코드와 파일들이 많아 지게 되는데요.

중간에 추상화 된 레이어가 존재하기 때문인데,

분업화 (혹은 모듈화) 하는 과정에서 어쩔 수 없는 부분입니다.

 

하지만 이것을 사용함으로 인해 모듈화가 명확해지고,

모듈의 교체도 유연해지고 유지 보수도 쉬워질 수 있겠네요.