iOS - Architectures [국산 앨런님]

k-elon.tistory.com/37

[iOS] Architectures (MV*, VIPER, ReactorKit, RIBs)

저도 여러번 포스팅하고 공부했지만 아키텍쳐라는 것은 사용하는 사람마다 이해하는 사람마다 전부 다르고해서 계속 안쓰면 까먹는 부분이다.

평소 MVC, MVVM만 알고 있었다면 다른 아키텍쳐도 국산앨런님 포스팅을 통해서 배워두면 좋을 것 같다.

 

---

저는 아키텍쳐를 어떻게 설계하는지에 대한 방법이라고 생각하고 있어요.

정리와 분배를 잘해야 협업에도 좋고 코드 짜기도 좋잖아요??

 

앨런님의 기준에 좋은 아키텍쳐란?

1. 각 객체들이 구체적이고 명확한 역할을 가지며, 그 역할이 적절하게 분배되어 있다.
2. 데이터의 흐름이 단순하다.
3. Testability 하다.
4. 코드의 위치가 명확하다.

라고하십니다. 

 

먼저 가장 흔하지만 기본적이고 중요한

MVC

 

코코아 MVC라고하시네요. 기존의 다른 플랫폼에서의 MVC와는 조금 다르다고합니다.

 

• Controller가 View Lifecycle과 강하게 연결되어있어 View와 Controller 간의 분리가 힘들다
• 역할의 분리가 되어있지 않아 Testability x
• Controller(View)에 모든 로직이 들어가 매우 비대해진다.

 

이렇기 때문에 다른 아키텍쳐에서는 뷰와 뷰컨트롤러를 합쳐서 뷰라고 부른다네요.

 

다음은 MVP

 

장점은

• View를 정적인 상태로 만든다 (할일 줄여주자)
• Presenter는 ViewLifecycle과 전혀 상관없다 
• Presenter는 Layout에 관련된 코드가 일체 없다. (관심사 분리)
• Presenter는 단지 View의 state와 data 를 업데이트한다.
• Testability : Present를 보면 unit test case 들을 알 수 있다.

단점은

• View와 Presenter가 1:1로 대응된다.
• Presenter 가 단순 중개자이기 때문에 여전히 View의 역할이 크다. (또는 불분명해진다.)
• Presenter의 코드가 빠르게 방대해진다.

다음은 MVVM

장점

• MVP 의 Presenter가 가지는 장점을 그대로 갖는다.
• View → ViewModel 바인딩 → View와 ViewModel 간의 의존성 제거 (단방향 이벤트 수신)
• Rx를 적극 활용할 수 있다.
• 데이터의 정제(상태변화)를 직접 관리하기 때문에 View의 역할을 줄여준다.

단점

• MVP에 비해 View의 역할이 많다. (ViewModel은 View를 직접 update 시키지 않는다)
• 아키텍쳐의 이해가 저마다 달라 ViewModel 역할 범위에 대한 논쟁이 많다...

외 다른 Viper, Reactorkit, RIBs등은 필요할 때 공부하는것으로??

일단은 하나라도 제대로해야겠당..

MVVM 딱 기다려