Modern Data Binding

데이터 바인딩 그러니까, 보이지 않는 Data를 보이는 View에 할당 시키는 과정

이런 개념은 사용자 인터페이스가 존재하는 모든 곳에서 사용되어지고 있다.

하고싶은 포스팅은 이것들의 기초적인 방법과 개념에 대한 것이다.

단순 참조

가장 심플한 방법으로써, View가 계속해서 Data를 참조하고 있는 구조이다.

이는 View가 Render가 될 때, 해당 데이터를 직접 표시한다.

View - Data

Pros

• 데이터 변경되면, 즉시 반영된다.(Auto Refresh)

Cons

• 데이터는 무조건 메모리에 있어야 한다.

풀링(데이터 요청)

View에서 Data가 필요할 때, Request을 통해서, 데이터를 가져오는 방법

View - Request/Response - Data

요청/응답에 대한 오버헤드는 없다고 가정

Pros

• 데이터의 위치가 자유롭다.

Cons

• 데이터가 변경되었는지 곧바로 알 수가 없다.

이벤트 기반 시스템 / 옵저버 패턴(Observer Pattern)

데이터 요청방식의 단점인 데이터 변경을 보완한 방법이라고 볼 수 있다.

Data의 변경은 Event이며, 이를 View가 Listen하는 것으로, Handler를 통해 Refresh가 가능해진다.

View - Request/Response - Data

Data - Event - View

Pros

• 데이터의 위치가 자유롭다.
• 데이터 변경시, 처리 가능(Handling)

Cons

• 이번 포스팅에서 다룬 것중에는 없음

핵심은, Data 변경 이벤트에 View를 등록했다는 점이다.

데이터를 가져오는 주체가 View에서 Data자체로 변경되었다.

단순한 signal/notification이라 하여도, 그 주체는 Data이고, Data가 View를 Control하고 있는 것이다.

기승전 이벤트

옵저버 패턴을 구현에 있어서는, 훨씬 다양한 것들이 또 존재하지만, 이번 포스팅은 여기까지