데이터 바인딩과 Reactive X

데이터 바인딩이란?

클린아키텍쳐에서 마틴 파울러가 말하는 GUI프로그래밍

The View is the humble object that is hard to test. The code in this obejct is kep as simple as possible.

The presenter is the testable object. Its job is to accept data from the application and format it for presentation so thaat the View can simply move it to the screen.

험블오브젝트 패턴에 의해 GUI는 두 개로 나뉜다 바로 뷰(구체적 구현사항)와 프레젠터(테스터블한 행동들)이다.

Anything and everything that appears on the screen, and that the application has some kind of control over, is represented in the ViewMdoel as a string, or a boolean, or an enum. Nothing is left for the View to do other than to load the data from the view model into the screen. Thus the View is humble

UI관련 코드는 최대한 "humble"하게 만들어야한다. 테스트하기가 어렵기 때문이다.
 
마이크로소프트에서 말하는 데이터 바인딩 정의

Data binding is the process that establishes a connection between the app UI and the data it displays. 

데이터 바인딩이란 UI와 보여줄 데이터를 연결짓는 작업이다.

Oneway binding causes changes to the source property to automatically update the target property, but changes to the target property are not propagated back to the source property. This type of binding is appropriate if the control being bound is implicitly read-only.

단방향 바인딩은 UI에 적용해야할 데이터 업데이트에 있어 read-only를 참조하는 것이 바람직하다.
 
웹이든, 모바일이든 어떤 GUI 프레임워크가 오든 상관없이 UI가 데이터에 의존성이 걸려있다는 사실은 바뀌지 않는다. MVVM은 수동적인 껍데기 객체로 만들어야하는 UI와 가변하는 데이터 변형로직을 분리함으로써 개발자로 하여금 로직적으로 명확한 분리 아래 프로그래밍할 수 있게끔 도와주는 패턴이다.    

---

iOS에서 자주 쓰이는 RxSwift  활용 데이터 바인딩 패턴

sergdort 예제
https://github.com/sergdort/CleanArchitectureRxSwift

import Foundation

protocol ViewModelType {
    associatedtype Input
    associatedtype Output
    
    func transform(input: Input) -> Output
}

1. 먼저 뷰모델 인터페이스를 만들어준다.
 

2. 인터페이스에 따라 input, output, transform 을 정의해준다.
 

3. 뷰컨에서 bindViewModel() 메서드를 사용해서 바인딩해준다.

 

💡 Driver는 핫옵저버블로 데이터 흐름의 일관성을 유지하고 여러뷰끼리의 공유를 가능케 해준다. 뿐만 아니라 UI 관련된 작업이기 때문에 error를 던지지 않고 메인스레드에서 오직 결과값으로만 던져주기 때문에 MVVM 데이터 바인딩 옵저버블 타입으로 적합하다.
 
💡 참고할만한 사항으로는 뷰와 뷰모델은 결국 presentation 아키텍쳐이기 때문에 fetch와 같은 비즈니스 로직 네이밍은 지양해야한다.

---

Rx 데이터 바인딩에 대한 나의 생각 

redux 아키텍쳐

 

개인적으로 프로젝트를 할 때 MVC보다 로직이 명확하게 분리되어 훨씬 편하다는 느낌을 받았다. 그럼에도 불구하고 MVVM + Rx 조합은 최선의 방법이 아니라 생각한다.  내가 생각하는 대안은 Rx+MVVM 대신 Combine+flux 조합이 가장 좋다고 생각한다. 

 

이유:

1. MVVM 패턴 자체는 아무리 인터페이스를 둔다하더라도 뷰와 뷰모델이 1대1 관계로 이어질 가능성이 크다.

2. 퍼스트파티를 쓰는 것이 유지보수측면에서 좋다 (Rx대신 Combine)

3. Flux에서는 이벤트 타입이 명시됨으로써 이벤트와 비즈니스로직의 관계가 더 느슨하다. 따라서 비즈니스 로직 메서드의 재사용성이 높아진다.

---

레퍼런스

https://viblo.asia/p/tim-hieu-ve-redux-saga-bWrZnODmlxw 

https://www.inflearn.com/course/ios-아키텍처패턴-이론/dashboard

https://learn.microsoft.com/en-us/dotnet/desktop/wpf/data/?view=netdesktop-8.0

Data binding overview - WPF .NET