본문 바로가기
Design Pattern/IOS - MVVM

IOS) kudoleh님 튜토리얼로 IOS MVVM 깊게 공부하기 - 2일차

by 후르륵짭짭 2022. 4. 10.
728x90
반응형

안녕하세요! 후르륵짭짭입니다.

천천히 MVVM을 평소에 알던 것을 넘어서 깊게 공부한지 3번째 공부 입니다 ㅎㅎㅎ

저도 해당 Sample 프로젝트의 코드를 하나씩 보면서 저만의 코드로 다시 구성을 해보고 있습니다.

이러면서 좀더 MVVM에 좀 더 가깝게 다다갈 수 있지 않을까 싶어서,,,,

 

일단 이 Sample 프로젝트 구성 부터 알아야 할 것 같습니다.

일단 이 구조를 보면 3개의 Layer 층으로 나눠져 있습니다.

Presentation Layer , Domain Layer , Data Layer 이렇게 구성이 되어 있죠 ㅎㅎㅎ

그럼 하나씩 보도록 하겠습니다.

Domain Layer (관리 층) : 도메인층은 제 3자의 간섭 없이 자기만의 영역을 의미합니다. 위의 그림을 보면 Data와 Presentation의 의존성 방향 모두 Domain을 가리키고 있습니다. 이것은 Domain이 하나의 고립된 자기만의 영역을 가진다고 보면 됩니다.

그럼 고유의 영역이라고 되는 것은 무엇이 있을까요??? 일단 제 3자의 계입이 필요 없는 Model , Interface가 될 겁니다. Model은 그 자체로 하나의 데이터 타입이기 때문에 Domain입니다. 그리고 Interface에는 Presentaion - Data의 연결 고리 역할을 하는 UseCase가 있을 겁니다. 

Usecase는 사용자의 사용방식에 대한 정의 입니다. 예를들어 A라는 사용자가 아이스크립을 먹는 씬이 있다고 하면 냉장고에서 아이스크립을 꺼내고 서랍에서 스푼을 꺼낸다 라는 것이 하나의 UseCase가 됩니다. UseCase에 부분은 아래에서 좀 더 쉽게 설명하도록 하겠습니다. 그냥 사용자의 하나의 씬을 정리한 것 입니다.

 

Data Layer (데이터 층) : 데이터층은 서비스와 연결 된 층입니다. 이 데이터 층에는 Repository와 Service가 포함이 됩니다. 이들은 모두  혼자서 어떤 역할을 한 다음 그 결과는 주는 층 입니다. 이 결과를 결국 도메인층에서 주는 것이죠. 

Service는 말 그래로 어떤 서비스 제공하는 객체 입니다. 주로 Realm Service , Network Service , JavaScripe Service 등 3rd Party Framework 등 다양한 기능들을 의미합니다. 

Repository는 각각의 Service를 제공하는 공간입니다. 예를들어 냉장고에서 사과랑 아이스크림을 꺼낸다고 하면 냉장고가 Repository이며 사과랑 아이스크림이 Service입니다. 즉 하나의 주제로 서비스의 공간을 제공하는 하나의 덩어리가 Repository라 할 수 있습니다.

 

Presentation Layer (보여주는 층): 프리젠테이션층은 말 그래돌 보여주는 층입니다. View와 View에 대한 로직을 담당하는 ViewModel이 포함됩니다. 

ViewModel은 View에 대한 필요한 정보를 정리 해서 보여주는 것 입니다. 그래서 MVVM(Model - View - ViewModel)에 View의 로직을 담당하는 ViewModel이 핵심 입니다.

 

여기까지 이제 기본적인 Layer에 대해서 알아봤습니다.

그럼 이제 MVVM의 작동은 어떻게 되는지 알 필요가 있습니다. MVVM은 Presentation과 Domain의 분리를 지향 합니다. Model(Domain) // View - ViewModel (Presentation) 이렇게 말입니다.

그러면 MVP(Model - View - Presentation)과 MVVM이 다른 것이 뭔지 궁금해 할 수 있습니다. MVP는 하나의 구성으로 움직입니다. 그러니깐 하나의 View에 하나의 Presenter가 있는 겁니다. 그래서 비슷한 10개의 View가 있다면 10개의 비슷한 Presenter가 있는 겁니다. 하지만 MVVM은 하나의 기준이 되는 View에 ViewModel이 존재하고 그 기준의 View에 하위 View들도 ViewModel을 사용합니다.즉 MVVM은 단체로 움직인다 생각하면 됩니다.

하지만 이 프로젝트는 MVVM을 더욱 알차게 사용하기 위해서 Coordinator Pattern과 DIContainer를 사용해서 더욱 복잡하게 만들었습니다. 그런데, 굉장히 좋은 방법이라고 생각합니다. 일단 이 이유는 MVVM이 기준이 되는 View에 있는 ViewModel을 여러 View에서 공통으로 사용한다고 말 했는데, 그 원칙을 준수 할 수 있게 해줍니다.

아래 이미지를 보면 AppDIContainer를 통해서 FlowCoordinator를 생성하고 이 Coordinator를 통해서 View의 생성, 이동을 관리하고 있습니다. 그리고 DIContainer를 통해서 의존성 관계를 더욱 명확하게 할 수 있도록 해줍니다. 

이것에 대한 설명은 다음에 직접 코드를 통해 보여주도록 하겠습니다. 지금 시간이 1:30이나 되서 그만 자러가야할 것 같습니다. 

감사합니다.

 

 

 

 

 

 

 

 

728x90
반응형

댓글