[디자인 패턴] Repository Pattern

728x90

리팩토링 2판을 공부하다가 Repository 패턴이 나와서 따로 정리해보려고 한다.

Repository 패턴이란

데이터와 상호작용하는 데 필요한 논리를 캡슐화하는데 중점을 둔 클래스 모음으로 정의할 수 있다.

더 구체적으로 설명하자면, 데이터 출처(로컬 DB, 서버 API 응답 등)와 관계 없이 동일 인터페이스로 데이터에 접속할 수 있도록 레포지토리를 만들어 관리하는 것을 말한다.

도입 배경

데이터를 사용하는 Domain에서는 비즈니스 로직에만 집중할 수 있으며 ViewModel은 데이터 출처를 신경 쓸 필요가 없고 여러 Repository를 공유하더라도 일관된 Interface를 통해 데이터의 일관성을 유지할 수 있다. 비즈니스 로직은 프로그램의 핵심이 되는 요소이며, 비즈니스 로직을 잘 짜야 원하는 결과를 올바르게 도출할 수 있다. 이때 비즈니스 로직은 보통 데이터베이스나 웹서비스 등의 데이터 저장소에 접근하게 되는데 이 과정에서 여러 문제가 발생할 수 있다. 주로 중복되는 코드, 오류를 발생할 가능성이 있는 코드, 오타, 비즈니스 로직 테스트의 어려움 등이 있다.

이에 따라 몇 가지 요구사항이 발생하는데,

(1) 비즈니스 로직과 데이터 레이어를 분리해야 하고

(2) 중앙 집중 처리 방식을 통해 일관된 데이터와 로직을 제공해야 한다는 것이다.

Repository 패턴 도입 전

위 캡처에서 계정 설정 컨트롤러와 제품 컨트롤러가 모두 사용자의 이름을 검색하기 위해서

자체적인 사용자 이름을 가져오기 메서드를 구현하고 있다. (코드 중복)

Repository 패턴 도입 후

개선한 코드는, 데이터 액세스 코드가 중앙 집중화되고 코드 중복이 사라졌다.

데이터와 상호 작용하는 방법에 대한 책임도 이전했다.

애플리케이션 레이어가 이제 인프라 계층에서 분리되어 서로 독립적으로 변강하기 위해 데이터와 상호 작용하는 방법에 때한 책임도 이전했다.

인터페이스를 사용하여 컨트롤러에 대한 리포지토리의 예상 동작만 정의하고 구현 세부 사항을 보호할 수 있다.

특정 orm apis와 같은 데이터 액세스에서 설계 선택을 고려할 때 확장성과 유연성을 제공한다.

이 기술의 핵심은 코드가 더 느슨하게 결합될수록 변경 및 유지 관리가 더 쉬워지고 전박적으로 더 큰 유연성을 갖게 된다는 것이다.

더이상 데이터를 제공하는 데 사용되는 하위 수준 인프라에 얽매이지 않게 된다.

Repository 패턴 : 요약 및 정리

특성

(1) 데이터가 있는 여러 저장소(Local Data Source, Remote Data Source)를 추상화하여 중앙 집중 처리 방식을 구현할 수 있다.

(2) 데이터를 사용하는 Domain에서는 비즈니스 로직에만 집중할 수 있다.
예를 들어, ViewModel에서는 데이터가 로컬 DB에서 오는지, 서버에서 API 응답을 통해 오는 것인지 출처를 몰라도 된다. Repository를 참조하여 Repository가 제공해주는 데이터를 이용하기만 하면 된다.

(3) Repository가 추상화되어 있으므로 항상 같은 Interface로 데이터를 요청할 수 있다.
ViewModel이 여러 Repository를 공유하더라도 일관된 Interface를 통해 데이터의 일관성 또한 유지할 수 있다.

장점
(1) 데이터 로직과 비즈니스 로직을 분리할 수 있다

(2) Domain에서는 일관된 인터페이스를 통해 데이터를 요청할 수 있다.

(3) 데이터 저장소의 데이터를 캡슐화할 수 있다. 객체지향적인 프로그래밍에 더 적합하다.

(4) 단위 테스트를 통한 검증이 가능하다.

(5) 객체 간의 결합도가 감소한다.

(6) 어플리케이션의 전체적인 디자인이 바뀌더라도 적용할 수 있는 유연한 아키텍쳐이다.

기타 참고 : https://velog.io/@shinsw627/Repository-Pattern-%EA%B5%AC%ED%98%84

https://4z7l.github.io/2020/11/24/repository-pattern.html