Skip to content

MVVM? or Clean Architecture 고찰에 대한 결과

S025_신명섭 edited this page Dec 1, 2021 · 9 revisions

MVVM? or Clean-Architecture 고찰에 대한 결과

Clean-Architecture에서 변경해야 했던 이유

  • 과연 우리가 Repository가 필요한가?

    • 서비스와 퍼시스턴스를 요청할 싱글톤이 있었기 때문에 사실 레포지토리의 역할을 대체하고 있어서 레포지토리의 존재 이유에 대하여 의심하기 시작했다.
    • 네트워크 로직이 없고 내장 프레임워크를 사용하는 싱글톤 서비스들에서, 꼭 레파지토리로 나누어서 처리를 해야하는 부분이 있을까? 생각하면 그저 데이터를 옮기는 작업만이 존재했음 -> 그러면 형태를 조금 바꿔서 설계하자 결론
  • MVVM(Clean Architecture 보다는 우리에게 맞게 아키텍처를 변경)


    • Repository가 없어짐으로 인해서 기존의 Clean-Architecture 라고 말할 수 없는 구조가 되었다. 그러나 각 Manager들에 접근할 존재는 필요했고, 해당 로직을 ViewModel에서 모두 처리하기에는 ViewModel의 크기가 커지기에 UseCase를 남겨두고 해당 비지니스 로직을 UseCase에서 처리했다.


  • MVVM, Usecase를 사용한 이유 ?
    View와 ViewController, ViewModel을 서로 분리하여 UIKit에 관계없이 View에 보여질 데이터들을 테스트 할 수 있는 구조를 위해 MVVM을 도입하였습니다. 또한 ViewModel이 직접 각 Manager들에 접근하게 되면 ViewModel의 역할이 비대해지게 되므로 이를 분리할 필요성 또한 느껴졌습니다.

  • Singleton 형태의 Manager를 도입한 이유 ?
    HealthKit의 HKHealthStore와 CoreData의 Persistent 모두 앱의 생명주기와 유사하게 길게 사용되는(long-lived objects) 객체들입니다.

    필요할 때마다 객체들을 인스턴스화하여 만들고 난 후 해당 객체의 레퍼런스를 넘겨 이용하는 것보다, 앱 전반적으로 CoreData와 HealthKit을 계속 접근하고 있어 싱글톤으로 만드는 것이 더 좋은 선택 이라고 생각했습니다.

    You need only a single HealthKit store per app. These are long-lived objects; you create the store once, and keep a reference for later use. -  Setting Up HealthKit

    Typically, you initialize Core Data during your app’s startup. Create the persistent container as a lazy variable to defer instantiation until its first use in your app’s delegate. - Setting Up Core Data Stack

Booster🚀🔥

Info

Rule

Backlog

공통 모듈

구현 설명 및 기능 정리

Architecture

Architecture

회의록 & DailyScrum & 회고록

멘토링 피드백

멘토링 피드백
Clone this wiki locally