摘要：前言本文講述的數據模型并不是一個庫，也不是需要的包，僅僅只是一種在多人團隊協作開發的時候擬定的規則。至少目前為止，我們的開發團隊再也沒用過雖然一開始也沒用，也不用擔心后臺數據的字段或結構發生變動，真正實現前后臺并行開發的愉快模式。

本文講述的數據模型并不是一個庫，也不是需要npm的包，僅僅只是一種在多人團隊協作開發的時候擬定的規則。至少目前為止，我們的開發團隊再也沒用過mock（雖然一開始也沒用），也不用擔心后臺數據的字段或結構發生變動，真正實現前后臺并行開發的愉快模式。

本文技術棧有 Typescript、Rxjs、AngularX

類比于java里的類，我們的Model也是一個類，是TS的類，我們根據需求和設計圖或原型圖規劃好某一個具體的模塊的基類Model，并自行定義一些字段和枚舉類型，方法屬性等，并不需要強行和后臺的字段一致，要保證百分百純的前后端分離，舉個例子

比如開發某一個后臺管理項目，里邊有產品（Product）模塊、用戶（User）模塊等

那么我們會在model文件夾里定義BaseProduct的基類

export class BaseProductModel {
    constructor() {}
    // 必有id 和 name
    public id: number = null;
    public name: string = "";
    /...more.../
}

基類的定義是必要的，可以節省很多不必要的代碼，并不需要寫一個頁面或組件就重新定義新的model，如果某一個組件里面需要對這個產品的內容進行拓展的大可直接繼承，并不會影響其他有了這個基類的文件

我們推崇一切基類都必須繼承，不可直接構造

真實的項目中產品的字段和屬性肯定不止只有id和name，可能還包含版本、縮略圖地址、唯一標識、產品、對應規格的價格、狀態、創建時間等等；這些屬性完全可以放在基類里，因為所有產品都有這些屬性，說到類型和狀態的定義，請注意

絕對不能將可枚舉性質的屬性直接使用后臺或第三方返回的對應屬性

比如，產品模塊里最基礎的狀態（status）屬性，假設后臺定義的對應狀態有

0: 禁用
1: 啟用
2: 隱藏
3: 不可購買

這四種，倘若我們在項目當中直接使用這些對應狀態的數字去判斷或進行邏輯處理，分不分的清另談，如果中途或以后狀態的數字變了，GG。可能大家覺得這樣的情況很少，但也不是沒有，一旦出現改起來BUG就一堆。

所以對于這種可枚舉性質的屬性我們會定義一個枚舉類（Enum）

export enum EStatus {
    BAN = 0,
    OPEN = 1,
    HIDE = 2,
    NOTBUY = 3
}

然后在model里這樣

export class BaseProductModel {
    // ......
    public status: string = EStatus[1] // 默認啟用
}

美滋滋，而且在進行邏輯判斷的時候我們也不用去關心每個狀態對應的數字是什么，我們只關心它是BAN還是OPEN，簡潔明了不含糊

而且我們還可以給model增加一個只讀屬性，用來返回這個狀態對應的中文提示（這種需求很常見）

public get conversionStatusHint() : string {
    const _ = { BAN: "禁用", OPEN: "啟用", HIDE: "隱藏", NOTBUY: "買不得呀" }
    return _[this.status] ? _[this.status] : ""
}

這樣就不用在每一個組件里面寫一個方法來傳參數返回中文名稱了

到了這里，我們的BaseProductModel已經算是定義好了，下面我們就需要給這個model定義一個方法

目的是把后臺返回的字段和數據結構轉化為我們自己定義的字段和數據結構

可能到了這里很多人會覺得這是多此一舉，后臺都直接返回數據了還轉化什么，返回什么用什么就得了。
但在大型的團隊開發項目當中，誰也不能保證一個字段也不修改，一個字段也不刪除或增加或缺失，牽一發動全身。人生苦短。而且還有一種情況就是，可能這個項目是前端先進行，后臺還未介入，需要前端這邊先把整體的功能和樣式都先根據設計圖規劃開發。

export class BaseProductModel {
    // ......
    // 轉化后臺數據
    public setData( data: BaseProductModel ): void {
        if (data) {
            for (let e in this) {
                if ((