Swift Clean Architecture를 공부하면서 참고한 프로젝트에서 usecase와 repository가 나오는데 둘에 대한 개념과 왜 사용하는지 모르겠습니다. 그래서 이번에는 두 용어 중 하나인 Repository에 대해서 알아보겠습니다.
Repository
repository는 Repository Pattern에서 사용되며, 데이터 소스와 애플리케이션의 비즈니스 로직을 분리하는 데이터 접근 계층을 의미합니다. 특정 데이터 모델에 대한 CRUD(Create, Read, Update, Delete) 작업을 처리하며, 이때 비즈니스 로직은 포함되지 않습니다. 다음과 같은 특징을 가지고 있습니다.
특징
-
데이터 접근 추상화
리포지토리는 데이터 소스(예: 데이터베이스, API, 파일 시스템 등)에 대한 접근을 추상화하며, 이를 통해 애플리케이션의 다른 부분이 데이터 소스의 구현 세부사항에 의존하지 않도록 합니다. -
비즈니스 로직과의 분리
리포지토리는 데이터에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행하지만 비즈니스 로직을 포함하지 않습니다. 비즈니스 로직은 Use Case에서 처리되며, 리포지토리는 단순히 데이터 접근을 담당합니다. -
유연성
리포지토리를 사용하면 데이터 소스를 쉽게 변경할 수 있습니다. 예를 들어, 로컬 데이터베이스에서 원격 API로 데이터 소스를 변경하더라도 리포지토리의 인터페이스를 통해 접근하므로 비즈니스 로직에는 영향을 주지 않습니다. -
테스트 용이성
리포지토리를 인터페이스로 정의하고, 이를 구현하는 여러 클래스를 만들 수 있습니다. 이를 통해 테스트할 때 가짜(mock) 리포지토리를 사용하여 외부 의존성을 줄이고, 단위 테스트를 쉽게 수행할 수 있습니다.
구성 요소
- 프로토콜
CRUD 메서드와 필요한 데이터 접근 메서드를 포함하는 리포지토리의 프로토콜
protocol UserRepository {
func getUser(by id: Int) -> User?
func saveUser(_ user: User)
}- 구현 클래스
실제 데이터 소스에 대한 접근을 처리하는 클래스로 데이터베이스, API 등 다양한 데이터 소스에 대한 구현을 제공합니다.
class UserDatabaseRepository: UserRepository {
private var users: [Int: User] = [:]
func getUser(by id: Int) -> User? {
return users[id]
}
func saveUser(_ user: User) {
users[user.id] = user
}
}Repository Pattern
모든 앱은 어떤 형태로든 데이터를 가지고 있으며, 데이터는 대부분 서버와의 통신을 통해 CRUD 작업을 수행합니다. 이러한 데이터들은 모두 다른 포맷을 가지고 있고, 우리는 이 데이터를 일련의 구조로 만들어 사용합니다. 만들어진 구조화된 데이터들은 모두 각기 다른 struct 혹은 class의 형태로 가지고 있게 되고 Repository Pattern을 사용하지 않는 앱에서는 일반적으로 ViewController 또는 ViewModel에서 데이터들을 직접 가지고 있습니다.
이때 왜 문제가 되냐면 나중에 유지보수가 힘들기 때문입니다. 앱이 작을 때는 데이터의 형태가 바껴도 수정할 부분이 몇 개 없지만 앱이 커지고 뷰가 많아지면 데이터 형태가 바뀌면 이에 해당하는 모든 부분을 수정해줘야 하며 이때 많은 자원을 소비하게 됩니다.
이를 완화하기 위해 나온게 Repository Pattern입니다. 이 패턴은 데이터와 DO(Domain Object) 사이에 Repository를 둠으로써 DO에서 필요한 형태로 Repository가 매핑해줍니다. 즉, 데이터의 형태가 변경되도 해당 데이터와 관련된 Repository만 수정하면 되기 때문에 자원 소비를 줄일 수 있습니다.
Repository Pattern을 썼을 때 장점은 다음과 같습니다.
1. 유지보수가 용이하다. 위에서 언급했듯이 데이터 소스가 변경되도 클라이언트 코드에 미치는 영향이 적습니다.
2. 테스트할 때 용이하다. 데이터 소스와의 의존성을 줄여서, 단위 테스트를 쉽게 수행할 수 있습니다.
3. 코드 재사용성이 좋다. 동일한 데이터 소스를 매핑을 통해 여러 곳에서 재사용할 수 있습니다.
물론 단점들도 있습니다.
1. 복잡성이 증가한다. 레파지토리 패턴을 도입하면 코드 구조가 복잡해질 수 있습니다.
2. 중간 계층이 추가되므로, 성능에 영향을 줄 수 있습니다.
3. 각 객체별로 모두 Domain Object에 맵핑하는 추가 작업이 필요합니다.
Reference
