👀 [Android Repository Pattern]을 사용하는 이유 알아보기!

프로젝트 중 Repository Pattern에 대해서 적용하게 되었다.

이전 프로젝트에서는 왜 Repository의 구현체인터페이스 , DataSource의 인터페이스와 구현체로 나누어서 총 4개의 파일에서 작업해야할지 명확히 이해하지 못했다. 그냥 한번에 한 클래스에서 작성하면 어떤 문제가 생기는 것인거지? 하는  생각을 가지고 있었다..

 

느낀 점을 하나씩 정리해보면 Repostiory pattern을 사용하지 않으면 어떤 점이 불편한지 직접 느낄 수 있겠다고 생각했고 

이번 프로젝트를 하며 Repository Pattern을 사용해야하는 이유를 정리해보려고 한다.

 

우선 지금까지 Repository Pattern을 사용하면 편했던 점과 불편했던 점을 공유해보면

레포지토리 패턴에 대한 감상 : 편리한 점과 불편한 점 

편리한 점

- 1. api 관련 변경사항이 있으면 data 디렉토리에서 repostiory와 datasource 부분에만 관심을 두고 변경된 내용을 반영해주면 되기 때문에 복잡함이 없었다. 

- 2. 특히 이전 프로젝트는 코드 규모가 큰 편이라서 한 화면에서 서버와 일어나는 상호작용도 다수 존재했다.

만약 repostiroy pattern을 사용하지 않고 Fragment나 뷰모델에서 모든 것을 관리했다면 코드 복잡도가 엄청났을 거라고 생각한다 😇😇😇

 

- 3. repository pattern 관련은 아니지만 UI레이어에 코드가 집중되었을 때는 
프필요한 로직을 작성해야할 상황에 구현해야할 기능도 생각하고 어디에 코드를 작성했는지 찾아야해서 정말 힘들었다. 

repository와 source 폴더 내 파일들이당ㅎㅎ

한 뷰모델에서 보여주는 정보가 많을 경우 + 사용자와 상호작용하는 내용이 많을 때 코드를 분리하지 않고 작업할 시 어떨지 상상해보자....

 

다시 돌아와서 레포지토리 패턴 사용으로 인해 데이터 액세스 코드를 분리한 것에서 가장 먼저 와닿은 이점은

1. 코드의 가독성

2. 관련 로직을 찾는 데까지 드는 에너지를 거의 0의 상태로 만들기

3. 코드 변경 시 그 부분만 변경하면 된다.

4. 그리고 마지막으로 A와 B 화면에서 좋아요를 등록하는 로직이 필요하다면 이를 중복으로 작성할 필요 없이 함수를 호출하여 공유할 수 있다는 점이었다. 

이제보니 이 점들만으로도 개발 중의 어려움을 대폭 줄여주었다고 생각한다..⭐️⭐️

불편했던 점

- 한 api가 추가되면 4개의 파일에 업데이트해줘야하는 것이 번거로웠다.

아무래도 repostiroy와 datasource는 거의 비슷한 메소드를 가지고 있어서 중복으로 작성해주는게 조금 번거로웠던 것 같다.

---

그러나 !!
명확한 근거를 가지고 레포지토리 패턴을 적용하는 사고를 기르고 싶기 때문에 좀 더 구체적으로 내용을 파악해보도록 하자!! 

데이터 레이어 분리해야하는 이유 

이제 데이터 레이어 안으로 파고들어서 Repository와 Datasource, 각각을 왜 인터페이스와 구현체로 구분하는지도 알아보았다. 

우선 저장소와 데이터 소스로 나누는 이유는 다른 레이어에서 데이터 소스에 직접 접근하지 못하도록 하기 위함이다

 

이를 캡슐화라고 한다. 각 계층은 다른 계층이 내부적으로 어떻게 작동하는지 알지 못한 채로 나의 책임에 집중하는 것을 말한다.

만약 프래그먼트에서 데이터를 가져오는 코드가 포함되어있으면 어떻게 되는지 코드로 이해해보자

// UI에서 바로 데이터를 쿼리하는 경우

val userDao = db.userDao()
val users = userDao.getAllUsers()  // SELECT id, name, email FROM users

binding.txtUserEmail.text = users.email 

// 수정 필요 
binding.txtUserEmail.text = users.userEmail

 

만약 데이터 베이스의 email 이름이 user_email으로 변경된다면 ?? 

users.email을 사용하는 모든 UI 관련 로직도 변경해주어야한다 ㅠㅠ

 

그러나 만약 데이터를 가져오는 로직을 UI 레이어에서 분리한다면??

class DefaultUserRepository @Inject constructor(
	private val userDao : UserDao) {
    
    fun getAllUsers() : List<User> {
     return userDao.getAllUsers() 
     }
 }


// UI
val users = userRepository.getAllUsers()
for (user in users) {
 	binding.txtUserEmail.text = user.email
    // 변경 없이 그대로 사용해도 된다
   }

 

만약 데이터 모델에서 변경된 열 이름을 반영해준다면 UI에서는 데이터 레이아의 변경사항에 영향없이 사용할 수 있게 된다.

즉 데이터 레이어에 밀접한 관계를 가지고 있다면 데이터 레이어 상의 변경이 UI 레이어 상의 변경까지 필요로 하여 오류가 발생하기 쉽고 오시간이 많이 걸릴 수 있다. 일일이 다 수정해줘야해서 기능 구현에 집중하지 못할 것이다..😅

 

이렇게 UI 상에서 데이터 레이어 관련 로직을 분리해야하는 이유를 간단한 코드로 이해해보았다.

실제로 프로젝트 하면서 여러 번 겪었던 상황이라서 간단한 코드를 통해 상상해보며 그때가 떠올라 더욱 잘 와닿았다.. ㅎㅎ 

 

즉 계층 구조의 다른 레이어는 데이터 소스에 직접 접근해서는 안되고 항상 리포지토리 클래스를 통해서 진입해야한다!!

---

Repository : 인터페이스와 구현체

이제는 왜 구현체와 인터페이스로 나눠서 작성해줘야하는지 알아보자.

앞서서 데이터 소스는 다른 레이어에서 접근하지 않도록 해야한다고 했다. 

이를 위해 repository와 datasource로 코드를 분리한 것이다. 그런데 repository를 interface와 구현체로 나누지 않고 바로 사용한다면 뷰모델에서는 결국 repository에 있는 데이터 소스에 대한 의존성을 가지게 된다. repository를 통해 api 호출을 하기 위해 객체를 생성할 때 데이터 소스 객체도 필요해진다..!!! 

그럼 지금까지 코드를 분리한 것이 의미가 없어져버릴 것이다.

 

따라서 아래와 같이 뷰모델이 가지고 있을 객체인 repository는 인터페이스로 구현하여 데이터 소스에 대한 의존성을 가지지 않도록 추상화해주고, 구현체에 데이터 소스와 함께 코드를 작성해주도록 한다.

interface WordRepository {
    suspend fun getFiveBasicWords(): Flow<List<BasicWord>>
    suspend fun updateStatus(word: String)
}

class DefaultWordRepository
    @Inject
    constructor(
        private val dataSource: WordDataSource,
    ) : WordRepository {
        override suspend fun getFiveBasicWords(): Flow<List<BasicWord>> = dataSource.getFiveBasicWords()

        override suspend fun updateStatus(word: String) = dataSource.markWordAsLearned(word)
    }

---

Datasource : 인터페이스와 구현체

그럼 뷰모델은 레포지토리의 객체를 가지고 있기 때문에 데이터 소스에 대한 의존성을 가지는 것을 막기 위해서  레포지토리를 추상화해야한다는 것을 이해가 되었을 것이다.

그러면 datasource는 왜 인터페이스와 구현체로 나눠줘야할까?

어차피 datasource에 대한 의존성을 가지고 있는 것은 repository뿐일텐데....??!!!

 

Repository는 Datasource와 상호작용한다. 데이터의 출처(로컬인지 원격 서버인지)는 중요하지 않고 데이터를 가져오거나 추가, 업데이트만 할수 있다. 실제 데이터 액세스 로직는 인터페이스 뒤에 숨겨져있다ㅏ.

 

알아본 결과 테스트 시 Datasource 인터페이스를 모의할 수있기 때문에 실제 데이터 베이스나 api 호출 없이 저장소 로직을 테스트할 수있다고 한다.

또한 레포지토리나 뷰모델에 대한 수정 없이 Datasource의 구현체를 수정하는 것만으로 데이터를 가져오는 로직을 변경할 수 있다.

예를 들어 SQLite에서 Room으로 로직을 수정하는 등의 작업을 수정할 때를 Datasource의 구현체만 수정해주면 변경사항을 반영할 있을 것이다.

---

마무리이

 

오늘은 레포지토리 패턴을 왜 사용하는지, 왜. 인터페이스와 구현체로 나누어서 코드를 작성해주는지 알아보았다. 그동안은 명확한 근거보다는 동료 개발자분이 이렇게 사용하고 계셔서, 권장되는 방법이라는 이유만으로 한 적이 많았는데 실제로 정리해보니 앞으로는 명확한 근거를 가지고 사용할 수 있을 것 같다.

 

아직 데이터 소스의 테스트에 관한 경험이 없어 확 와닿지는 않았지만 이번 프로젝트를 진행하면 테스트 코드도 작성해봐야겠다