요즘 MVVM 패턴을 배워가면서 가장 많이 하는 질문이

“이 코드가 여기 있어야될 이유가 있을까?” 라는 질문이다. 그 질문에서 파생되었던 것이

바로 MVVM에 있는 서버통신 코드였다.

@objc func editCompleteButtonDidTap(){
        viewModel.patchPetProfile()
    }

protocol MyEditNetworkHandlerProtocol {
    func patchMyPetProfile()
}

extension MyEditProfileViewModel: MyEditNetworkHandlerProtocol {
    func patchMyPetProfile() {
        MyAPI.shared.patchMyProfile(requset: editProfileDataOutput.value) { result in
            switch result {
            case .success(_):
                self.editCompletedOutput.value = true
                NotificationCenter.default.post(name: .homeVCUpdate, object: nil)
                NotificationCenter.default.post(name: .myPageUpdate, object: nil)
            default:
                self.editCompletedOutput.value = false
            }
        }
    }
}

아직 텍스트로 완전히 설명할만큼 개념이 박혀있지 않아서 모호하게 내가 느낀건

“뷰모델에서 서버통신 로직이 통째로 들어가있는게 좋은 구조인가?” 라는 의문이었다.

즉 viewModel안에서도 서버통신을 따로 다루면 훨씬 더 좋지 않을까?가 내 결론이었다

그렇게 장석우그는감히섹시개발자라할수있다 님께 여쭤보게되었고 Repository 패턴에 대해 알게 되었다,

Repository Pattern

디자인 패턴으로 데이터의 추상화를 제공하여 어플리케이션이 추상화된 인터페이스로 작업할 수 있게해준다.

여기서 가장 핵심이 되는 단어가 바로 데이터!

즉 데이터를 받아오고 가져오는 과정을 비즈니스 로직과 분리하는거라고 볼 수 있다.

정말 아래 설명이 딱 맞는 표현인거 같다!

<aside> 💡 Repository는 데이터 소스에 접근하기 위해 캡슐화된 구성요소입니다. 데이터에 접근하는 기능을 한군데에 집중시켜서, 유지보수에 용이하고, 데이터 구조에 대한 의존성 낮추게 됩니다. 이로써 앱이 데이터를 다루는 곳과 이 데이터를 표현하는 곳으로 명확하게 나뉘게 되는 것입니다.

</aside>

장점으로

• 결합도를 낮출 수 있다.
• 정의된 인터페이스를 구현하는 mock에 DI 할 수 있으므로 테스팅하기 쉽다.
• viewModel 밑에 Repository라는 layer를 하나 더 두어서 viewModel은 오직 비즈니스로직만 집중하게 할 수 있다.

라는 것들이 있습니다!