[Android] Repository Pattern 의 이해

Repository Pattern이란?

데이터 출처와 관계 없이 동일 인터페이스로 데이터에 접근할 수 있도록 만드는 것을 Repository 패턴이라고 합니다.

레포지토리는 데이터 소스에 접근하는 데 필요한 논리를 캡슐화하는 클래스 또는 구성 요소입니다.

Repository 패턴을 사용하는 이유

Repositoires are classes or componets that encapsulate the logic requriedto aceess data soruces

Repository는 DataSource 를 캡슐화 한다.

• 데이터 로직을 분리시킬 수 있다.
• 중앙 집중처리 방식으로, 언제나 일관된 인터페이스로 데이터를 요청할 수 있다.
• 그렇기 때문에, 클라이언트가 어떤 데이터를 사용할지 선택할 필요 없이, 어떤 데이터를 가져올지는 Repository에서 결정하여 적절한 데이터를 제공한다.
• 단위 테스트를 통해 검증이 가능해집니다.
• 새로운 데이터 로직 코드를 쉽게 추가할 수 있습니다.

Repository 클래스에서 담당하는 작업은 다음과 같습니다.

• 앱의 나머지 부분에 데이터 노출
• 데이터 변경사항을 한 곳에 집중
• 여러 데이터 소스 간의 충돌 해결
• 앱의 나머지 부분에서 데이터 소스 추상화
• 비즈니스 로직 포함

각 데이터 소스 클래스는 파일, 네트워크 소스, 로컬 데이터베이스 같은 하나의 데이터 소스만 사용해야 합니다. 데이터 소스 클래스는 데이터 작업을 위해 애플리케이션과 시스템 간의 가교 역할을 합니다.

Repository 패턴의 이점

하나의 도메인을 표현하는데 필요한 DataSource가 몇개 든 client쪽에서는 이를 알 필요가 없다.

따라서 DataSource가 새롭게 추가되는 것에 대한 부담이 없다.

DataSource의 변경이 발생하더라도 repository 외부 layer로 전파되지 않는다.

client는 repository 인터페이스에 의존하기 때문에 테스트하기 용이하다.

결국 respository는 presentation layer와 data layer 의 Coupling(결합도)를 느슨하게 만들어준다.

중간에 추상화된 레이어로서 Repository 클래스를 두어 모듈화가 명확해지고, 유지보수성이 향상된다.

 

단점

추상레이어가 하나 추가되는 것이므로 관리해야 할 코드와 파일들이 많아진다.

 

안드로이드에서의 Repository 패턴

View -> Presenter / Viewmodel -> Repository -> DataSource(API, LocalDB)

 

MVVM

 

 

Repository는 ViewModel or Presenter가 요청하는 데이터를 로컬DB(Room) 또는 서버(Retrofit)로부터 가져와 전달해준다. 이를 통해 ViewModel은 누구한테 가져온 데이터인지(Local DB인지, 서버인지)에 대해 신경쓸 필요가 없어진다.

즉, ViewModel은 자신의 비즈니스 로직에만 집중하면 된다.

Relam인지, Room인지, Retrofit을 통한 http서비스를 통해서인지, SharedPrference인지 등 데이터의 출처를 ViewModel은 전혀 신경쓰지 않아도 된다. Repository가 처리해주기 때문이다.

 repository 는 Presenter 계층과 data 계층의 coupling 을 느슨하게 만들어준다.

 

Q. "DataSource를 새롭게 추가하는 것에 대한 부담이 줄어든다."의 의미가 무엇인가.

레포지토리 패턴을 사용한다는 것은 DataSurce 즉, Data Layer를 캡슐화한다는 의미이다.

따라서 DataSource의 변경이 발생하더라도, 캡슐화를 통해 변경사항은 알 필요 없이, interface로 

 

 

 

* 캡슐화

 

캡슐화(영어: encapsulation)는 객체 지향 프로그래밍에서 다음 2가지 측면이 있다:

• 객체의 속성(data fields)과 행위(메서드, methods)를 하나로 묶고,
• 실제 구현 내용 일부를 외부에 감추어 은닉한다.

외부에 감추는 방법으로는 언어적 측면에서 접근지정자를 두어 은닉의 정도를 기술하여 구현한다. 은닉의 정도를 접근지정자로 기술하고 해당 영역에 들어가는 속성이나 메서드를 제한하면 된다. 접근지정자에 의해 제한된 멤버들은 컴파일러에 의해 판단된다. 언어적 측면에서 접근지정자에 의해 정의된 해당 멤버변수나 멤버함수는 코드 중에 접근방식을 위반한 코드를 작성하면 컴파일 오류로 처리하고 실행코드 생성을 제한한다.

 

정보은닉을 하게되면 객체의 내부로직을 알 수 없게 되고 접근할 수 있는 부분이 제한되기 때문에 다른 코드와의 결합도가 낮아진다. 때문에 코드의 변경에 유연하게 대처할 수 있다.

 

즉, 속살을 드러내지 말고 interface만 제공해라~

정보은닉을 하는 이유는 변경에 유연하게 대처하기 위해서다.