vue中資料繫結原理的設計模式到底觀察者還是發布訂閱？

1樓：熊貓px

1.init過程 vue生命週期中先 init初始化初始化資料的函式中 initState函式觸發initwatch 觸發createWatcher 觸發$watch $watch才是真正的監聽函式,建立乙個watcher例項, 觸發watcher的get方法將watcher推送到，dep.target

2.initData中觸發observe observe使用obj.defineproperty進行資料劫持

3.在 getting 中判斷dep.target 是的話通過 dep的depend方法,觸發watcher的addDep方法觸發dep的addsub,將watcher 新增到訂閱者陣列中在setting中去觸發 dep的notify方法遍歷觸發所有訂閱者的update方法

dep是發布-訂閱模式的中間管理者,通過他的notify去發布通過addsup去新增訂閱者列表

setter相當於發布者 watcher相當於訂閱者

自己的理解錯了勿噴

2樓：Rick

個人愚見，觀察者模式。

觀察者模式和發布訂閱還是有區別的。後者是解偶的。

即觀察者模式為只要值發生變化，就會通知到訂閱者。

而發布訂閱模式是改變歸改變，通知歸通知，中間可以做許可權控制。

而dep的寫法其實是發布訂閱模式的寫法，但是因為有defineProperty，導致只要值改變就會觸發notify。

所以是觀察者模式。

END。。。

3樓：水完熊

不敢大聲bb。個人感覺這兩種合起來就是觀察者模式了。之前一直覺得angular的zone.

js是採取類似思想實現雙向繫結的，不過看起來vue也是類似。不過zone.js應該是劫持的瀏覽器事件，vue劫持的是資料set get。

這可能也是導致寫angular之後改用vue會發現一些資料沒法雙向繫結，因為zone.js劫持的全域性事件總能識別到資料變化。但vue必須在元件裡有註冊觀察者才能識別到，也就是外部來的變數必須在當前元件有宣告註冊。

當然這樣看起來明顯vue效率高。如果有不對的地方請指正，沒做過很多vue專案

4樓：餘騰靖

pub/sub，observable/watcher，eventbus，event emitter，message channel，message bridge，技術以改名為本。

5樓：賀師俊

首先，資料繫結是宣告式的，你可以認為是一種魔法，反正就繫結了，本身是無所謂觀察者模式還是發布訂閱模式的。

資料繫結的底層實現，可以使用觀察者模式或發布訂閱模式。這兩個模式，如果一定要做區分，那麼就是，發布訂閱模式中發布者和訂閱者是解耦的。資料繫結這個具體場景本身並不必然要求解耦，但解耦可能有好處（比如效能）。

然後具體到Vue的實現原理（尤其是Vue3）。Vue對其資料繫結的底層實現的官方稱謂是反應式系統（Reactivity System）。此系統其實和經典的觀察者模式或發布訂閱模式相當不同。

無論用哪個模式來比較都有很多關鍵特徵不吻合。

相比較而言，Rx或許更接近觀察者模式或發布訂閱模式，但嚴格說來也都不是。因為Rx的重點是流的處理和變換。一定要說的話，算是乙個糅合了傳統觀察者模式或發布訂閱模式的新模式。

Vue的反應式系統也是類似的，只不過缺少像Rx那樣普遍的跨語言實現，因此還難以成為乙個普適的「模式」。部分原因可能是大部分語言並沒有類似JS的Proxy機制，即使有也相當不同，所以移植起來不容易，但長期看來是有可能的。

另外，Rx或Vue反應式系統的這種「模式」實際上已經脫離了「設計模式」的定義（針對特定問題的通用解法），而更接近程式設計正規化了。

vue中資料繫結原理的設計模式到底觀察者還是發布訂閱？

WPF中資料繫結的乙個小疑問？

MVC 模式的原理，它在 Android 中是如何運用的？

（翻譯）Rust中的設計模式 4 The Default Trait

其他用戶還看了：