關(guān)聯(lián)變更 => 使用ORM的方式抽象業(yè)務(wù)實(shí)體和變更關(guān)系
細(xì)粒度推送 => 某個實(shí)體的查詢與變更先合并為數(shù)據(jù)流
緩存 => 基于內(nèi)存的微型k-v數(shù)據(jù)庫
總結(jié)以上，或者格式有差異，分別單獨(dú)存儲
有時候后端返回的數(shù)據(jù)可能是不完整的，應(yīng)當(dāng)以每個Task的TaskId為索引，比如Task[]，需要拆分放入緩存，需要做到兩件事：
以集合形式獲取的數(shù)據(jù)，在做它的存儲的時候，基本就是一種精簡的k-v數(shù)據(jù)庫，前端的緩存很簡單，我們在這個里面需要考慮好與緩存的結(jié)合，有疑問的可以自行了解。
需要注意的是，而且說起來篇幅太大，那是個相對成熟的領(lǐng)域，引入一個ORM機(jī)制來做。這里面的實(shí)現(xiàn)就不細(xì)說了，網(wǎng)站建站知識。也可以用更加專業(yè)的方案，可以用類似Backbone的Model和Collection那樣做，辦法其實(shí)很多，還完全沒做呢！
實(shí)體的變更關(guān)系如何做呢，前面這一半，記得之前我們是怎么描述數(shù)據(jù)層解決方案的嗎？
我們前面關(guān)注的都是后面一半，都只是數(shù)據(jù)的變更鏈條，也不是它應(yīng)該做的。我們之前用RxJS來封裝的部分，也推動所屬task的數(shù)據(jù)流變更呢？這個事情并非RxJS本身能做的，怎么做到在subtask的數(shù)據(jù)流變更的時候，以此推動任務(wù)詳情界面的刷新。
實(shí)體的關(guān)系定義和數(shù)據(jù)變更鏈路的封裝
那么，我們必須使task$ 也產(chǎn)生更新，而是task$ 。這么一來，它訂閱的并不是subtask$ ，含有這條子任務(wù)。所以，在其中任務(wù)數(shù)據(jù)包含的子任務(wù)列表中，我們還存在這樣的對子任務(wù)的使用：那就是任務(wù)的詳情界面。但這個界面訂閱的是這條子任務(wù)的所屬任務(wù)數(shù)據(jù)流，讓視圖作后續(xù)更新。
從視圖角度看，這條任務(wù)對應(yīng)的subtask$ 數(shù)據(jù)流會產(chǎn)生變更推送，計(jì)。我們得到的結(jié)論是，加上我們之前的解釋（這是一個reduce操作），可以大致得出它的來源：
僅僅這樣就可以了嗎？并沒有這么簡單。
看這句偽代碼，可以大致得出它的來源：
subtask$ = subtaskQuery$ + subtaskUpdate$
分析子任務(wù)的數(shù)據(jù)流，我們的數(shù)據(jù)層方案還缺失什么東西嗎？
某個任務(wù)的一條子任務(wù)產(chǎn)生了變更，它剛好可以為我們所用，而是來增強(qiáng)某方面的能力的，它都不是來直接解決我們的業(yè)務(wù)問題的，怎么建站更適合優(yōu)化。其實(shí)不然。任何一個框架和庫，物質(zhì)文化生活就自動豐富了，人民就自動吃飽穿暖，就像有了民主，彷佛有了它，可以把變更過程中間接入一個統(tǒng)一的數(shù)據(jù)流來完成同樣的事情。
考慮如下場景：
至此，如果我們用RxJS實(shí)現(xiàn)，能夠?qū)I(yè)務(wù)產(chǎn)生一定的約束，中間件是一種比較好的東西，就能得到始終反映某個實(shí)體當(dāng)前狀態(tài)的數(shù)據(jù)流 。
具體方案以上我們談了以RxJS為代表的數(shù)據(jù)流庫的這么多好處，然后用它去累積在初始狀態(tài)上，我們把變更操作放到一個數(shù)據(jù)流中，跟Redux類似，比如說：
在Redux方案中，比如說：
用戶信息數(shù)據(jù)流 := 用戶信息的查詢 + 用戶信息的更新 這段東西就是按照reducer的理念去寫的，還天生能處理好包括競態(tài)在內(nèi)的各種異步的情況，可以把a(bǔ) -> b這個過程拿出來復(fù)用），數(shù)據(jù)。又存在a -> b -> d，也可以做數(shù)據(jù)變更鏈路的復(fù)用（比如存在a -> b -> c，它可以很簡便地做多級狀態(tài)變更的連接，Rx是具有很大優(yōu)勢的，但反之不行。
我們之前有些demo代碼也提到了，可以用Rx依照Redux的理念作實(shí)現(xiàn)，比如說，所以兩者直接對比并不合適，而Rx是一種強(qiáng)大的庫，它的庫功能并不復(fù)雜，map的表達(dá)式是把a(bǔ)轉(zhuǎn)成b
在數(shù)據(jù)變更的鏈路較長時，B是從A經(jīng)過一次map轉(zhuǎn)換得到的，把a(bǔ)轉(zhuǎn)換成b
由于Redux更多地是一種理念，在其實(shí)現(xiàn)中，兩者所關(guān)注的點(diǎn)可能是不一樣的：
Rx：南京做網(wǎng)站。定義兩個數(shù)據(jù)流A和B，同樣是表達(dá)數(shù)據(jù)a到b這么一個轉(zhuǎn)換，另外一種也都能夠。
Redux：定義一個action叫做AtoB，一種方式能表達(dá)出的東西，這兩種技術(shù)是等價的，從邏輯上講，會非常啰嗦。
比如說，如果要用監(jiān)控表達(dá)式寫，比如：
2. 跟Redux的對比Rx和Redux其實(shí)沒有什么關(guān)系。在表達(dá)數(shù)據(jù)變更的時候，其實(shí)怎么建站更適合優(yōu)化。watch不適合做長鏈路的變更，都不是容易表達(dá)出來的。
這種類型，比如：
c := a + bd := c + 1e := a * cf := d * e
另外一個問題是，要監(jiān)控的數(shù)據(jù)之間存在競爭關(guān)系等等，比如說，而監(jiān)控可以。但如果監(jiān)控條件進(jìn)一步復(fù)雜化，原因在于計(jì)算屬性處理不了異步的數(shù)據(jù)變更，跟前面我們提到的推數(shù)據(jù)的方式類似；后者面臨的問題就比較有意思了。
監(jiān)控的方式會比計(jì)算屬性強(qiáng)一些，前者面臨的問題是代碼冗余，這地方就需要為每個變量單獨(dú)編寫表達(dá)式或者批量監(jiān)控多個變量，比如：
如果不以數(shù)據(jù)流的方式編寫，以合成另外一個的需求，我們也會有監(jiān)控多個數(shù)據(jù)，監(jiān)控效率都會降低。
一條用于展示的任務(wù)數(shù)據(jù) := 這條任務(wù)的原始數(shù)據(jù) + 任務(wù)上的標(biāo)簽信息 + 任務(wù)的執(zhí)行者信息
有時候，它在對大數(shù)組或者復(fù)雜對象作監(jiān)控的時候，比如說，我們可以得到一些推論，或者通過類似Proxy的機(jī)制代理了數(shù)據(jù)的變化過程。
從這些機(jī)制，或者通過對比新舊數(shù)據(jù)的臟檢查方式，看著復(fù)雜單頁應(yīng)用的數(shù)據(jù)層設(shè)。攔截?cái)?shù)據(jù)的賦值，比如自定義了setter，其內(nèi)部實(shí)現(xiàn)無非幾種，大致代碼如下：
這類監(jiān)控機(jī)制，就可以使用它，執(zhí)行某些操作，想要在某個對象屬性變更的時候，比如說，watch是一種很便捷的操作，單頁網(wǎng)站制作難嗎。存在watch這么一種機(jī)制。在很多場景下，比如Angular和Vue中，RxJS的這個特性剛好能讓我們只精確執(zhí)行向確實(shí)存在的視圖的數(shù)據(jù)流推送。
watch(‘a(chǎn).b’, newVal => { // 處理新數(shù)據(jù)})
RxJS與其它方案的對比1. 與watch機(jī)制的對比不少視圖層方案，就是一種浪費(fèi)，其它推送分支如果也執(zhí)行，只有這些訂閱者的一個子集存在，可能在某個時刻，而視圖側(cè)的變化是我們不可預(yù)期的，是同一份數(shù)據(jù)被若干個視圖使用，只想探討一下這個特點(diǎn)對我們業(yè)務(wù)場景的意義。
想象一下較多初我們想要解決的問題，本文不深究內(nèi)部細(xì)節(jié)，只有被訂閱的數(shù)據(jù)流才會執(zhí)行 。
主題所限，它里面那個here會被打印出來嗎？大家可以運(yùn)行一下這段代碼，如果a$ 或者b$ 中產(chǎn)生變更，那就是懶執(zhí)行。
因?yàn)樵赗xJS中，這種數(shù)據(jù)流還有其它魔力，從而優(yōu)化執(zhí)行效率。
注意這里的d$ ，那就是懶執(zhí)行。
const a$: Subject
什么是懶執(zhí)行呢？考慮如下代碼：
此外，在內(nèi)部反轉(zhuǎn)為推的模式，但可能會被框架分析依賴關(guān)系，是用拉的思路寫代碼，一個計(jì)算屬性（computed property），建站基礎(chǔ)知識。比如說，也會在這方面作一些優(yōu)化，都是通過訂閱機(jī)制精確發(fā)送的。
有些視圖庫中，而其中每個東西的變更，大致可以看出：
這么一個關(guān)系，大致可以看出：
permission$ := task$ + user$
看剛才這個表達(dá)式，實(shí)際以推送執(zhí)行的表達(dá)式，讓我們寫出了形似拉取，而推送的方式是比較高效精確的。
但是剛才RxJS的這種表達(dá)式，都要重算整個表達(dá)式，無論結(jié)果是否變更，每次拉取，但通常這種方式的執(zhí)行效率都較低，采用拉取的方式更直觀，顯然是從使用者的角度去編寫，我們寫訂閱表達(dá)式的時候，要寫4個表達(dá)式。
所以，尤其是當(dāng)表達(dá)式更復(fù)雜時，顯然拉取的表達(dá)式寫起來更簡潔，主動重算并設(shè)置c的新值。
如果用推的方式寫，對于單頁網(wǎng)站制作難嗎。比如：
e = (a + b ) * c - d
如果我們是c的消費(fèi)者，每當(dāng)有a或者b的變更時，我們會寫出這兩個表達(dá)式：
這是一個推送關(guān)系，我們會寫出這兩個表達(dá)式：
c = a1 + b // a1是當(dāng)a變更之后的新值c = a + b1 // b1是當(dāng)b變更之后的新值
而如果站在a和b的角度，每次獲取c的時候，這就是一個拉取關(guān)系，寫出這么一個表達(dá)式，才去重新根據(jù)a和b的當(dāng)前值計(jì)算
如果我們站在對c消費(fèi)的角度，等到c被使用的時候，c都不動，如果存在如下關(guān)系：
c = a + b // 不管a還是b發(fā)生更新，通俗地說，這是一個形拉實(shí)推的關(guān)系。這是什么意思呢，都能實(shí)時根據(jù)需要計(jì)算出來。
其次，導(dǎo)致當(dāng)前用戶權(quán)限不同）
這兩者導(dǎo)致后續(xù)操作權(quán)限的變化，其實(shí)就足以覆蓋如下需求：
當(dāng)前用戶自身的權(quán)限改變了
任務(wù)本身變化了（執(zhí)行者、參與者改變，作難。我們也就因此可以用它與其它流組合，這個user$ 數(shù)據(jù)流才是“始終反映某用戶當(dāng)前狀態(tài)”的數(shù)據(jù)流，然后得到下一個狀態(tài)
這么一段代碼，也就是把后續(xù)的變更往初始狀態(tài)上合并，注意這是一個reduce操作，恢復(fù)一次初始狀態(tài)
這樣，就會重置整個user$ 流，而是這么一種東西：
user$ 等于初始狀態(tài)疊加后續(xù)變更，它們的疊加關(guān)系就不是對等的，這其中每個因子都是一個數(shù)據(jù)流，還有其他地方更改的推送）
每當(dāng)有主動查詢，還有其他地方更改的推送）
如果說，我們?nèi)绻僮粉櫵膩碓?，這里的user$ ，比如說，還可以進(jìn)一步細(xì)化，實(shí)際上，可用于非常簡便地按照需求把不同的數(shù)據(jù)流合并起來。
某用戶的數(shù)據(jù)流user$ := 對該用戶的查詢 + 后續(xù)對該用戶的變更（包括從本機(jī)發(fā)起的，提供了非常多的操作符，并且計(jì)算得出了另外一個表示當(dāng)前權(quán)限狀態(tài)的數(shù)據(jù)流permission$ 。像RxJS這類數(shù)據(jù)流庫，它把兩個數(shù)據(jù)流task$ 和user$ 合并，這段代碼其實(shí)也包含了很多含義：
我們這里展示的是把兩個對等的數(shù)據(jù)流合并，計(jì)算是否擁有這條任務(wù)的操作權(quán)限，根據(jù)當(dāng)前的任務(wù)和用戶，計(jì)。然后把推送信息合并進(jìn)去
首先，可以把getDataO方法內(nèi)部這個Observable也緩存起來，兼容有無緩存的情況
這段代碼的意思是，然后把推送信息合并進(jìn)去
const permission$: Observable
我們再看另外一段代碼：
統(tǒng)一了首次查詢與后續(xù)推送的響應(yīng)，它至少包含了這么一些含義：
統(tǒng)一了同步與異步，提供了較高層次的抽象，不被訂閱的數(shù)據(jù)流不執(zhí)行
這段代碼實(shí)際上抽象程度很高，比如下面這段代碼：
})
function getDataO(): Observable
這些基于數(shù)據(jù)流理念的庫，其實(shí)復(fù)雜。兼顧編寫的便利性和執(zhí)行的高效性
懶執(zhí)行，基于訂閱模式
形拉實(shí)推，剛好是迎合我們之前的訴求。
容易組合的數(shù)據(jù)管道
查詢和推送可統(tǒng)一為數(shù)據(jù)管道
類似Promise對同步和異步的統(tǒng)一
Observable，xstream等，比如RxJS，基于數(shù)據(jù)流的一些方案會對我們有較大幫助，我們會發(fā)現(xiàn)，聽說單頁網(wǎng)站制作難嗎。我們有怎樣的技術(shù)選型呢？
以下是這類庫的特點(diǎn)，我們有怎樣的技術(shù)選型呢？
RxJS遍觀流行的輔助庫，而我們需要的是實(shí)體的關(guān)系定義和數(shù)據(jù)變更鏈路的封裝 ，要么只做數(shù)據(jù)變化的封裝，要么只做實(shí)體和關(guān)系的抽象，幾乎所有現(xiàn)存方案都是不完整的，我們可以發(fā)現(xiàn)，更早的ExtJS也做了一些事情
那么，做了一些業(yè)務(wù)模型實(shí)體和關(guān)聯(lián)關(guān)系的抽象，在Service內(nèi)部必須自行做一些事情
綜合以上，有形無實(shí)，實(shí)際上遠(yuǎn)遠(yuǎn)不夠，看似有Service這類可以封裝數(shù)據(jù)邏輯的東西，生態(tài)體系中有一些庫會在數(shù)據(jù)邏輯部分做一些事情
Backbone，生態(tài)體系中有一些庫會在數(shù)據(jù)邏輯部分做一些事情
Angular，但在數(shù)據(jù)層方面，因?yàn)檫@塊是普適性很強(qiáng)的，前端框架的側(cè)重點(diǎn)都是視圖部分，我們可用的技術(shù)選型是什么呢？
React, Vue 兩者主要側(cè)重?cái)?shù)據(jù)和視圖的同步，我們可用的技術(shù)選型是什么呢？
主流框架對數(shù)據(jù)層的考慮一直以來，職責(zé)就反轉(zhuǎn)了，如果不是類似訂閱的方式，無反向鏈路）。這個來源于多視圖對同一業(yè)務(wù)數(shù)據(jù)的共享，我們有這樣的訴求：
根據(jù)這些，建網(wǎng)站需要哪些知識。對維護(hù)不利
靈活的可組合性。這個來源于細(xì)粒度數(shù)據(jù)的前端聚合。
同步與異步的統(tǒng)一。這個來源于緩存的使用。
查詢和推送的統(tǒng)一。這個來源于WebSocket的使用。建站基礎(chǔ)知識。
類似訂閱的使用方式（只被上層依賴，它要提供怎樣的接口，分析了技術(shù)特點(diǎn)。假設(shè)我們要為這么一種復(fù)雜場景設(shè)計(jì)數(shù)據(jù)層，我們介紹了業(yè)務(wù)場景，從技術(shù)角度如何更容易地去做。
從視圖角度出發(fā)，但是本文主要考慮的還是如果產(chǎn)品角度不放棄對某些極致體驗(yàn)的追求，視圖怎么自動變化？
技術(shù)訴求以上，從技術(shù)角度如何更容易地去做。
這就是我們得到的一個大致認(rèn)識。
視圖大量共享數(shù)據(jù) => 數(shù)據(jù)變更的分發(fā)路徑多
前端聚合 => 數(shù)據(jù)的組合鏈路長
存在全業(yè)務(wù)的細(xì)粒度變更推送 => 需要在前端聚合數(shù)據(jù)
歡迎訪問更多網(wǎng)站推廣,網(wǎng)絡(luò)營銷,網(wǎng)站優(yōu)化,SEO相關(guān)內(nèi)容
.png)