ViewState는 꽤 여러가지 것들을 포함하고 있습니다. Navigation Stack 뿐 아니라 View Update의 트리거가 되는 모든 액션들을 포함합니다. (https://github.com/objcio/app-architecture/blob/master/Recordings-MVC%2BVS/Recordings/ViewState.swift) 기존 MVC에서 Model에 해당하는 부분을 Document Model에 대응시키고, ViewController가 갖고 있던 각종 ViewState를 ViewState Model에 대응시켰습니다. 동작 자체는 MVC와 동일합니다.
ViewState를 분리해 관리함으로써 얻을 수 있는 장점 중 하나는 ViewState의 save/restore가 용이해진다는 점입니다. ViewState가 Codable을 conform하도록 했기 때문에, UIApplicationDelegate.application(_, willEncodeRestorableStateWith:)와 UIApplicationDelegate.application(_, didDecodeRestorableStateWith:)를 손쉽게 구현할 수 있습니다. 또한, User Interaction을 테스팅할 경우, ViewState의 값을 비교하는 방식으로 단위 테스트를 작성하는 것이 가능해집니다. 또한 여러 ViewController들이 ViewState를 공유해야하는 경우에 유용하다고 합니다.
단점은 ViewState를 분리해 관리하는 것 자체가 손이 많이 가고, Navigation Stack의 변화를 observe할 수 있는 방법이 없기 때문에 이를 ViewState에 저장하고 동기화시키기 위해 UINavigationControllerDelegate를 구현해야 합니다. ViewController들이 ViewState를 공유해야하는 경우에 유용하다고 하지만 대안은 많습니다.
MVC+VS가 괜찮은지 아닌지를 떠나서, 앱과 각 화면들이 가질 ViewState를 일일이 정의하는 것이 과연 가능한 지 의문이 듭니다. 여러 사람이 함께 개발하는 환경을 상상해보면 거기에 또 룰이 필요해지고, ViewState의 범위마저 각자의 추상화 레벨에 따라 달라질테니 금새 누더기가 되지 않겠는가 싶은 거죠.
App Architecture. Networking (0) | 2019.05.02 |
---|---|
App Architecture. Model-View-ViewModel+Coordinator (0) | 2019.01.27 |
App Architecture. Model-View-Controller (0) | 2018.08.21 |
App Architecture. Overview of Application Design Patterns (0) | 2018.08.17 |
댓글 영역