[디자인패턴] Repository Pattern 레포지토리 패턴

Repository Pattern ?

데이터 레이어를 분리한 디자인 패턴.

데이터 레이어: UI 와는 별도로 앱의 데이터와 비즈니스 로직을 처리하는 앱 레이어 부분, 다른 레리어에서 데이터 레이어에서 제공하는 API 를 통해서 이 데이터에 액세스 할 수 있다.

UI 가 사용자에게 정보를 제공하는 동안 데이터 레이어에는 네트워킹 코드, Room 데이터베이스, 데이터 관련 오류 및 예외 처리, 데이터를 읽거나 조작하는 코드 등이 포함된다.

-

• 저장소를 구체적으로 몰라도 중앙에 위치한 Repository에서 추상화하여 처리하는 방식.
• Data 의 출처에 관계없이 동일한 인터페이스로 데이터에 접근할 수 있도록 하는 패턴
• Repositories 는 데이터 소스 간 충돌을 해결, 데이터의 변경사항을 중앙 집중화할 수 있다.
• DataSource 가 Local 이면 Room, SQlite, Remote 면 서버와 api 통신하는 특정한 목적들을 알 수 없이 우리는 필요한 데이터만 요청하게 되므로, 캡슐화된다.

 

 

장점

Repository 모듈은 데이터 작업을 처리하고 여러 백엔드 APi 사용을 한 곳에서 가능하게 한다.

일반적인 앱에서 저장소는 네트워크에서 데이터를 가져올지, 로컬 DB 에 캐시된 결과를 사용할지 결정하는 로직을 구현한다. MVVM 의 경우 뷰모델이 위 같은 역할을 한다.

 

 

//TODO Example

// TODO:: Repository + Pager  순서를 어떻게 해야하는지 더 찾아보기.

 

Etc

 

Singleton 패턴과는 달리 Repository 패턴이 블로그 포스트나 책에서 쉽게 보이지 않았다.

 

아마 이 stackoverflow의 답변처럼, 구조적인 패턴이라 명확한 카테고리로 분류하기가 어려운 것 같다.

패턴을 분류하는 것은 어려울 수 있습니다. GOF 책에 패턴 카테고리를 추가한 것은 사실이지만, 대부분의 경우 사람들은 패턴 카테고리는 커녕 건축 스타일 의 디자인 패턴 인지도 알아낼 수 없습니다 .
리포지토리 패턴은 GOF 책 이후에 출판된 Patterns of Enterprise Application Architecture 책에서 소개되었습니다 .

정의에 따르면: "리포지토리는 도메인과 데이터 매핑 계층 사이를 중재합니다."

우리는 이것이 구조적 패턴 이라고 말할 수 있습니다 .
때때로 사람들은 Repository를 사용하여 객체를 생성하기도 하므로 이 경우 Creational 패턴 일 수도 있습니다 .
그래서 얼마나 많은 책임을 부여받았느냐에 따라 다르지만, 대부분의 경우 창조 패턴 으로 분류할 수 있습니다 .
패턴으로서 리포지토리에는 다양한 변형이 있으므로 카테고리에 넣기가 어렵습니다. 또한 책임이 무엇인지, 구현 방법 등에 대해 많은 논의가 있습니다.
사람들이 이러한 트랜잭션 을 관리하고 DB에 변경 사항을 저장하는 Unif Of Work 와 함께 ACID 트랜잭션을 지원하는 데이터베이스에 대한 매핑 레이어가 있는 리포지토리를 사용하기 시작했다는 것은 말할 것도 없습니다 .
요즘 사람들은 MongoDB와 Event Sourcing을 사용하고 여기에 .Save 와 같은 추가 메서드를 추가합니다 . 이러한 방법은 많은 논의를 불러일으킵니다.
https://stackoverflow.com/questions/55896518/is-repository-pattern-a-design-pattern (의 답변을 자동번역한 것)

 

Reference

https://velog.io/@ilil1/Repository-Pattern-%EC%9D%B4%EB%9E%80