-
Notifications
You must be signed in to change notification settings - Fork 3
MVVM? or 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