前端數據層的探索與實踐（一）

時間 2019-11-25

標籤前端數據探索實踐简体版

原文原文鏈接

第一部分：前端數據層的探索與實踐（一）
第二部分：前端數據層的探索與實踐（二）html

契機

在使用redux的過程當中，因爲業務複雜度的提高，store裏面存儲的數據愈來愈多，一般會有多層次的嵌套和重複數據。同時在與後端交互的過程當中，咱們常常會討論是否要按照UI的層次結構來返回數據，結果被後端駁回，由於若是後端從數據庫中取到數據後，還要特地爲前端加一層轉換，一來是考慮到服務器壓力，二來是考慮到多設備的時候沒法複用接口。前端

在這樣的契機之下，我開始思考，面對複雜的應用，前端也須要處理業務邏輯，那麼數據應該如何組織和管理？vue

三種方案

此次我先講範式化數據。數據庫

範式化

所謂「範式化」，就是數據庫設計時使用的一系列原理與技術。在講範式以前，咱們先說一下你們都不陌生的關係型數據庫，這就是應用範式化的典型。redux

關係型數據庫：創建在關係模型上的數據庫。後端

關係模型：若干個存儲數據的二維表，每一行稱爲一條記錄，每一列稱爲一個字段。表與表之間用關係來描述，有一對一/一對多/多對多三種關係。服務器

藉此兩個概念很容易想到咱們接觸得很是多的數據庫。那關係型數據庫在存儲和管理數據的時候遵循哪些原則呢，見下：

第一範式（1NF）：表列（或稱屬性或稱字段）具備原子性，不可再分。

第二範式（2NF）：知足1NF的前提下，錶行（或稱實例）必須具備惟一能夠被區分的主鍵key

第三範式（3NF）：知足1NF&&2NF的前提下，每一個表中不包含已在其餘表中定義的非關鍵字段，也就是不能有冗餘數據。

前端範式化數據

明白了範式化的概念與設計原則，咱們以Redux應用爲例，看一下咱們應該怎樣設計範式化數據，先看一個簡單的例子，咱們組織數據一般是這樣：

咱們分析以上這個例子，能夠看出實體有article/author/comment/commenter，對應設計爲數據庫表的時候能夠建三張表user/comment/article，因此範式化數據應該像這樣：

總結：

每種類型的數據應該具備本身的表,
每張表存儲在對象中，對象中的每一個元素即爲一條記錄，用id做爲key,數據內容做爲value
數據A與數據B的關係經過ID來描述

這樣帶來的好處顯而易見：

數據更加扁平化，最多隻有一層
數據間的關係清晰
數據項是惟一的，減小冗餘
reducer再也不須要深層次嵌套處理數據
更新數據項時，更新只會發生在當前項，不會對引用該數據項的地方作無必要的重複渲染
每一個組件能夠connect本身的數據，無需一層一層的向下傳遞數據（可提升性能）

應用

當服務器端把數據傳到前端的時候，咱們不太可能手動的去把這些數據範式化，好在咱們已經有了不少成熟的庫，幫咱們作轉化。在Redux應用中，推薦比較多的就是 Normalizr 了，這個庫主要是幫咱們將數據作範式化處理，輸出的數據能夠放在state中，顯然，這樣的範式化數據在store中進行手動處理，會很是不方便，也有這樣的庫來幫助咱們解決範式化數據在store中的問題，好比Denormalizr。可是還有一個更好的工具，Redux-ORM，它能夠說是Normalizr和Denormalizr的結合（若是是vue，也有相似的工具vuex-orm）。