티스토리 뷰

🍏/Design Pattern

[MVVM] MVVM 의 다양한 옵션들

사용자 eungding 2019. 7. 4. 01:49
728x90
반응형

 

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를 대응하게 해준 플젝이 있을 것만 같다. 어떤 모양인지 찾아봐야지~ 

 

 

 

 

728x90
반응형
댓글
  • 프로필사진 알파카 글 잘 봤습니다.
    한 가지 질문이 있는데요.

    위의 코드에서는 `MemosService` 서비스 레이어에서 ViewModel에서 쓸 데이터를 한 번 더 가공하고 있고 이를 서비스 레이어를 하나 더 두는 것의 장점이라고 하셨는데요.
    ViewModel에서 사용할 데이터는 해당 ViewModel에서 한 번 더 가공하는게 좀 더 낫지 않나 하는 생각이 들어서요.
    혹시 저렇게 하신 자세한 이유를 들을 수 있을까요?
    2020.11.27 15:04
  • 프로필사진 사용자 eungding 안녕하세요~~
    여기서 말하는 service는 보통 repository라고 말하는 데요! (참고: https://eunjin3786.tistory.com/198)

    repostiory라는 이름으로 말할게요!!

    우선

    1. Repository Layer를 두면 viewModel은 오직 비즈니스 로직만 집중할 수 있는 장점이 있습니다.

    데이터를 로컬과 서버 중 어디서 가져올지, 또 어떻게 가공할지는 Repostitory가 하기 때문입니다.

    특히 뷰모델이 여러개가 있을때, 특정 데이터를 가공하는 로직을 여러 뷰모델에 모두 둬야할까요,,,?! 레포지토리 하나가 데이터를 앱에서 필요한 데이터로 가공해주면 뷰모델에서 아예 신경쓸 필요가 없어집니당!

    2. Repository Layer를 두면
    예를들어 네트워크 라이브러리를 바꿔야하는 상황이 있을때 (ex. Alamofire 말고 다른 라이브러리를 쓴다고 할때,,)
    viewModel은 수정해야하는 코드가 없고
    Repostory코드만 수정해주면 됩니다.

    즉 viewModel이 네트워크 관련해서 의존성이 있는 상황이 아니기때문에
    1번과 마찬가지로 뷰모델의 로직에만 딱 집중하게 되는 점이 좋은 것 같습니다.

    3. Repository Layer를 두면 뷰모델에 RepositoryMock을 주입해서
    서버와 상관없이 내가 원하는 데이터로 뷰모델의 핵심 로직을 테스트할 수 있습니다.


    2020.11.27 22:45 신고
  • 프로필사진 sm 지금 MVP 하다가 MVVM을 하려고 하는데 MVP에서는 상시 들고 있어야 하는 유저데이터같은 경우 구조가 model - repository(싱글톤)으로 해서 repository안에서 userModel 객체를 갖고있는 것으로 관리하고 있었거든요 그러면 MVVM에서도 똑같이 싱글톤으로 관리를하면 될까요? 2021.06.30 11:39
  • 프로필사진 사용자 eungding 네! MVVM일 때도 똑같이 해주시면 될 것 같다고 생각합니다~ 2021.07.01 20:10 신고
  • 프로필사진 sm 감사합니다! 2021.07.01 22:21
댓글쓰기 폼