🌟🌱 알고 계실 것 🌱🌟
본 게시글은 저의 학습을 위한 용도라 부족한 점이 많을 수 있어요.
만약 틀린 부분이 있다면 따뜻한 조언과 피드백 부탁드립니다:) 🧚
공식문서에서는 앱 아키텍쳐를 가져갈 때 Repository pattern을 사용하라고 말하고 있다.
발생 배경
모든 앱은 작던, 크던 어느정도의 데이터를 갖고 있기 마련이다. 이 데이터는 어딘가에 저장이 되어있는데, 디바이스 자체 로컬 DB일수도, 또는 리모트 저장소일수도 있다. 하지만 그 데이터를 처리하는 과정인 비지니스 로직에서는 이런 저런 문제가 많이 발생한다.
이 데이터들은 각자의 데이터 구조를 가지고 있고, 또 어느순간엔 데이터에 접근하기 위한 메소드가 무조건 필요하다.
문제
그럼 어떤 문제가 있을까.
앱을 유지하기가 어려워진다. 작은 앱이라면 데이터도 적을 것이고, 변화가 있더라도 작은 변화만을 유지하면 되겠지만, 규모가 큰 앱이라면? 코어 데이터가 문제가 생긴다면? realm을 옮겨야하는 상황이 생긴다면? 모든 데이터 오브젝트를 수정할 순 없는 일이다. 언제나 '직접'무언가에 접근하는 일은 조심해야한다.
Repository Pattern
레포지토리 패턴이란 데이터 출처(logal DB or API Response) 와 관계 없이 동일 인터페이스로 데이터에 접속할 수 있도록 만드는 패턴이다.
사용하는 이유 및 장점
- 데이터 로직을 분리시킬 수 있다.
- Repository가 추상화 되어 있으므로, 중앙 집중 처리 방식으로서 일관된 인터페이스를 통해 데이터를 요청한다.
- 데이터를 사용하는 도메인 로직에서는 어떤 데이터를 사용할지 선택할 필요 없이 비지니스 로직에만 집중할 수 있다. ViewModel에서는 데이터가 로컬에서 오는지, 서버 API 응답을 통해 오는 것인지 출처를 몰라도 된다.
- 객체 간의 결합도가 감소한다.
- Application의 전체적인 디자인이 바뀌더라도 적용할 수 있는 유연한 아키텍쳐다.
결론
이번 프로젝트(안끝났지만)를 복기하면서 repository 패턴을 공부해보았다. 짜야하는 코드 량은 많아지지만, 결국 항상 현재의 번거로움은 나중의 나를 위한 것임을 생각한다.
Reference
Chocolate lover🍫 & Junior Android developer🤖