저희 팀에서만든 리포지토리 패턴 사용 깃허브 입니다.
github: https://github.com/Team-Trit/donworry-ios
유지보수를 위한 Repository Pattern
예)
1. CoreData -> Realm으로 바꿀 때.
2. 앱 전체에서 사용되고 있는 Codable 객체가 서버단에 의해 다른 구조로 바뀔때.
앱에 보여지게 되는 도메인 객체에 Repository를 통해 Mapping 한다.
따라서 앱에 보여지게 되는 Repository 부분만 바꾸면 된다.
즉 데이터에 접근하는 기능을 한군데에 집중시킨 것이고, 이를 통해 유지보수와 데이터 구조에 대한 의존성을 낮춘것. 도메인 오브젝트를 만들어 놓으면 된다.
서드파티 라이브러리에서 제공하는 데이터가 바뀌고 이를 그대로 앱에서 사용하는 경우엔, 모든것을 바꿔줘야하는 치명적인 이슈가 발생하게 되는 것입니다.
데이터레이어세의 DTO로부터 Domain에서 View에서 사용될 객체를 만듦으로써, Presentation layer에서는 DTO를 몰라도됨. 관심사 분리
Coredata예시.
NSManagedObject를 사용하여 앱의 Presentation Layer에서 직접 사용하는 것이 아니라, 필요한 Domain Object를 별도로 만들어서 NSManagedObject에서 뽑아온 객체를 각 Domain Object에 맞게 맵핑.
DTO를 Presentation layer에서 바로사용하면 API리스폰스 형태 바뀌면 수정어렵. completion handler에 DTO구조 넘기는게 아니라 도메인객체 넘긴다.도메인객체를 만듦으로써 DTO와 Presentation layer와 독립. 도메인객체는 MVVM의 경우 ViewModel에 들어간다.
Repository Pattern에서는 Repository로 분류된 곳에서 DTO를 사용하고, Presentation Layer(나타나지는곳)에서는 Domain Object 를 사용.
주목해야할 점 - completionHandler로 데이터응답을 전달할 때는 domainUser객체를 전달
이 덕분에 DomainObject하나로 PresentationLayer와 독립적인 데이터가 만들어지게 되는 것입니다.
데이터를 가져오는 곳(Data Source)과 데이터를 표현하는 곳이 강하게 결합되어 있는 문제를 Domain Object를 디자인하고 Repository에서 이를 변환함으로써 Decoupling 할 수 있는 것을 보았습니다.
원작자 분이 글을 참 잘쓰십니다.
참고: https://devming.medium.com/repository-pattern%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-255731577927
