App Architecture. Model-View-ViewModel+Coordinator

아무래도 저자가 이 책을 쓴 이유가 아닐까 하는 MVVM입니다. MVC와 유사해보이지만 ViewModel을 통해 MVC가 갖는 단점들을 개선하고 테스트 작성을 더욱 용이하게 해준다고 합니다.

https://github.com/objcio/app-architecture/tree/master/Recordings-MVVM-C

ViewModel

ViewController와 View 사이에 ViewModel이 추가된 구조로, ViewModel의 역할은 Model과 ViewController 사이의 dependency를 끊고 Model 변경 및 observing을 담당하며 observing된 event들을 ViewController에게 필요한 수준으로(purely data-related) transformation 해서 전달하는 것입니다.

Rx 이야기가 빠질 수 없죠. http://reactivex.io/ 대문에 걸려있는 정의를 보면 'An API for asynchronous programming with observable streams'라고 되어 있습니다. Observer 패턴은 Rx 없이도 여러 가지 방법으로 구현할 수 있겠지만, Observable들을 연계한다거나 전달받은 데이터를 View의 property에 바로 binding할 수 있다는 장점이 있습니다. 다만 개인적으로 RxCocoa를 사용해서 곧바로 binding하는 게 과연 괜찮은 걸까 약간의 의구심을 갖고 있습니다. 단순한 화면의 경우, ViewController가 하위 뷰를 모두 관장한다면 바로 binding하는 게 명쾌해보입니다. 하지만 View가 복잡할수록 하위의 CustomView에게 Model 객체을 넘겨주고 View configuration을 전담시키는 것이 일반적인 방법이라고 생각하는데, Rx binding을 사용하려면 하위의 CustomView에게 ViewModel을 전달해야 하고... 그렇게까지 해야하는가 싶은 거죠. -> 샘플 코드를 보니 해당 Model에 changeObservable을 구현하고 있던데, 그걸 이용해 binding 하면 될 것 같습니다.

바로 결론짓기보다는 동료와 여러 가지로 시험해보는 중입니다. 

Coordinator

Coordinator는 MVVM과는 직접적으로 연관되어 있지 않습니다. Coordinator의 역할은 기본적으로 ViewController의 present/dismiss를 관장하고, ViewModel에 Model 객체를 주입해서 ViewController에게 넘겨주는 것입니다. MVC의 단점 중 하나인 'Massive View Controller' 문제를 개선해주는 효과가 있습니다. 대놓고 설명하진 않지만 샘플 코드로 미루어 볼 때, Coordinator가 어떤 식으로든 window.rootViewController의 레퍼런스를 갖고 있어야하는 것으로 보입니다. 그렇지 않으면 present()를 호출할 주체를 늘 함께 전달받아야할 것이기 때문에 번거로움이 이만저만이 아니겠지요. 왠지 마음이 찜찜했지만, 형님들도 유사한 방식으로 구현하고 있기에(https://github.com/google/iosched-ios) 저도 그냥 믿고 따르기로 했습니다. (전 아예 singleton으로 정의버렸...)

Testing

ViewModel을 생성한 후 이를 subscribe하는 코드를 setUp()에 포함시켜놓고, Model을 변경했을 때 정상적으로 observing이 되는지 확인하는 테스트들을 선보이고 있습니다. ViewController에는 이제 화면 업데이트 코드들만 남아있으니 그 부분은 UnitTest가 아니라 UITest나 닝겐이 테스트하는 것이 낫다며 슬그머니 발을 빼는군요. 일단 시키는 대로 작성해보려고 합니다.

기타

레퍼런스를 확인하고 동료들에게 물어봐도... '아 이렇게 하면 되겠구나'하고 머리에 딱 떠오르진 않는 것 같습니다. 일단 좀 더 시행착오가 필요할 것 같습니다.