티스토리 뷰

반응형

 

iOS 디자인 패턴(MVC/MVVM/VIPER/Clean Swift/MVC-C /MVVM-C )    을 다 쓰지 못했지만...!ㅠㅠ 일단 정리

 

MVVM도 다양한 종류가 있어서 정리를 해보고자 한다 

ViewModel이 Model을 다루고 View는 다루지 않는다는 컨셉은 동일하고 두가지 옵션을 선택하여 쓰는 것 같다

 

1) ViewModel이 Coordinator(Navigation을 담당하는 녀석)에게 말하느냐 안하느냐 

 

MVVM에서는 Navigation 관련 코드를 Coordinator 또는 Navigtor라는 녀석에게 다 맡긴다.
보통 Coordinator라고 많이 부르고 이런 디자인 패턴을 MVVM-C 라고 부른다.

이 Coordinator에게 "여기 화면으로 이동 좀 해주세요~" 하는 요청을 ViewModel이 할 것이냐 ViewController가 할 것이냐를 선택할 수 있다 

 

1.1) ViewModel이 Cooridnator에게 말하는 경우

 

1.2) ViewController가 Coordinator에게 말하는 경우 

 

 

2) ViewModel이 APIMananger 쪽을 한겹 더 싼(?) Service layer를 가지느냐 안가지느냐 

 

2.1) Service Layer를 안 가지는 경우

FirebaseManager는 APIManager 역할을 하는데, 비교를 위해 fetchAll과 login함수만 예제 코드에 넣었다 

ViewModel들은 APIManager에 바로 접근한다 

 

 

** 장점 

간단하다 빠르게 코딩 끝 

 

** 단점 

 

2.2 에서 나오는 케이스인데, 

 API Manager가 주는 데이터를 한번 더 가공하는 경우 

같은 API를 쓰지만 다른 역할을 수행하는 함수가 여러개 필요한 경우

 

Service Layer가 없다면 APIManager에 이 경우들이 들어가게 되는데, APIManager의 layer가 살짝 애매해지는 것 같다

위의 케이스는 APIManager보다 한 겹 위의 일들인 것 같음 

2.2) Service Layer를 가지는 경우 

FirebaseManager에는 Auth관련된, DB관련된 API 이렇게 API 두가지 종류가 있다

개념 상 MemosServiceProtocol 과 LoginServiceProtocol로 나눠주고 그에 따른 클래스도 구현해준다 

그리고 viewModel 쪽을 보면 ServiceLayer를 가지고 있어서 바로 APIManager에 접근하지 않는 것을 볼 수 있다...!! 

 

 

** 장점

 

이렇게 나눠준 장점은 

MemosService를 보면 알 수 있는데, (말은 안되지만 밑의 것을 보여주기위해 내가 가정한 상황--!!!)

API Manager가 주는 데이터를 한번 더 가공하는 경우 

같은 API를 쓰지만 다른 역할을 수행하는 함수가 여러개 필요한 경우

 

유연하게 대처할 수 있다 

그리고 APIManager에 있던 많은 API 함수들이 개념별로 정리되고 한눈에 들어온다는 장점도 있다 ( 이것은 APIManager를 여러개로 분리하는 방법도 있을 것이다. LoginAPIManager, MemosAPIManager등... 하지만 APIManager가 있고 Service별로 나눠지는 코드가 있는 것이 나는 더 마음에 든다...!! )

 

그리고그리고 MemosServiceStub 같은 클래스를 만들어서 viewModel에 주입해주면서 유닛테스팅 하기도 좋다는 장점이 있다

(이건 코드로 첨부하겠음) 

 

** 단점 

 

단점까지는 아니지만 LoginService안의 함수처럼 아무 작업도 새로 안해주지만 한 겹이 더 생긴 것은 괜히 한 depth가 더 깊어진 느낌이 든다

 

** 궁금 

 

viewModel은 view와 상관없기 때문에(Model만 바라보고 있기 때문에) viewModel이 쓰는 API들만 service로 정의해준 것이 아니라 Model의 개념에 따라 service를 묶어주고 viewModel 쪽에서는 가지고 있는 서비스 중 쓸 것만 골라서 호출해준다 

 

하지만 어딘가 viewModel이 쓰는 API들을 service로 묶어서 viewModel - service를 대응하게 해준 플젝이 있을 것만 같다. 어떤 모양인지 찾아봐야지~ 

 

 

 

 

반응형
댓글