簡介

大家好，前端小白一枚，目前接觸后臺(tái)管理系統(tǒng)比較多，經(jīng)常遇到不同對(duì)象的增刪改查的接口，如何對(duì)Api進(jìn)行一個(gè)有比較好的管理是個(gè)問題。在學(xué)習(xí)偏函數(shù)的時(shí)候有了靈感，想到一個(gè)不錯(cuò)的API管理方案，并應(yīng)用在項(xiàng)目一個(gè)模塊當(dāng)中，并且開發(fā)效率和維護(hù)性可讀性都很不錯(cuò)，和大家分享一下~

當(dāng)前項(xiàng)目的前端API管理方案

// 封裝的接口
export function obj1Func1(){}
export function obj1Func2(){}
export function obj2Func3(){}
export function obj2Func4(){}

// 引入方式
import { obj1Func1, obj1Func2, obj2Func3, obj2Func4 } from 'xxx'

// 使用方式
const params = {...}
await obj1Func1(params)

// 封裝的接口
function obj1Func1(){}
function obj1Func2(){}
function obj2Func3(){}
function obj2Func4(){}
// 導(dǎo)出接口
export {
    obj1Func1,//注釋
    obj1Func2,//注釋
    obj2Func3,//注釋
    obj2Func4,//注釋
    ...
}

// 引入方式
import { obj1Func1, obj1Func2, obj2Func3, obj2Func4 } from 'xxx'

// 使用方式
const params = {...}
await obj1Func1(params)

優(yōu)點(diǎn)

• 面向?qū)ο?，不需要每個(gè)接口函數(shù)都引入，開發(fā)時(shí)調(diào)用方便
• 簡化操作類型命名，如update -> upd，開發(fā)和維護(hù)方便

缺點(diǎn)

• 當(dāng)模塊涉及的對(duì)象很多，則需要建立非常多的文件，當(dāng)文件名復(fù)雜時(shí)，難以看懂維護(hù)難度up。
• 當(dāng)頁面需要引入多個(gè)對(duì)象，需要引入一個(gè)個(gè)文件，降低開發(fā)效率。
• 找對(duì)象需要拖拽到文件最底部

以面向模塊（對(duì)象）的方式

假設(shè)當(dāng)前模塊下涉及到 n 個(gè)對(duì)象及對(duì)應(yīng)的增刪改查接口, 定義一個(gè)映射表

// api映射表
const apiMap = {
    // 公共接口
    common: {
        commonFun1,
        commonFun2,
    },
    //對(duì)象1
    dog: {
        //增刪改查
        add: obj1Func1
        get: obj1Func2
    },
    //對(duì)象2
    cat: {
        //增刪改查
        upd: obj2Func3,
        del: obj2Func4,
    },
    ...
}

export default {
    commonApi: apiMap['common'],
    dogApi: apiMap['dog'],
    catApi: apiMap['cat'],
}

import {commonApi,...} from "xxx"

面向模塊(多個(gè)對(duì)象)

本質(zhì)就是以對(duì)象的方式來進(jìn)行管理，只不過這里面向的是模塊。這里一個(gè)模塊只對(duì)應(yīng)一個(gè)文件，包含了涉及到的n個(gè)對(duì)象的接口。因?yàn)槲矣X得一個(gè)模塊下建n個(gè)對(duì)象一長串的Api文件，又沒法對(duì)文件名注釋（文件名總有不認(rèn)識(shí)或拼接的單詞吧）只會(huì)帶來更大的維護(hù)困難

找了幾個(gè)不常見的英語名詞，英語爛仔直接帶上痛苦面具
而有了映射表就相當(dāng)于有了一個(gè)目錄(文件最上方一目了然, Map下的對(duì)象十分清晰還有注釋)，
至少目前我是能都秒讀懂接口含義了
也不會(huì)出現(xiàn)面對(duì)老項(xiàng)目里那種長得拖不完的不知名接口文件的懵逼，點(diǎn)進(jìn)去還只有幾行代碼(雪花飄飄~)

優(yōu)點(diǎn)：

• 同上
• apiMap變成接口目錄，可讀性和可維護(hù)性提高(下方介紹)
• 涉及同模塊多個(gè)對(duì)象只需要引入一個(gè)文件

缺點(diǎn)：

• apiMap(目錄)和export的位置一個(gè)在文件最上方，一個(gè)在最下方，瀏覽時(shí)非常不方便，依舊需要經(jīng)常拖拽

這種方式已經(jīng)比較好用了，從可維護(hù)性和可讀性，拓展性來看我更推薦第二種方式

導(dǎo)出方式2

導(dǎo)出一個(gè)訪問映射表的函數(shù)，參數(shù)是對(duì)象及操作類型，如(dog, upd)

// 暴露一個(gè)訪問api映射表的函數(shù), 參數(shù)是對(duì)象和操作
// 這里沒有錯(cuò)誤處理，jym看懂就行
export default function api(obj, action) {
    if (action) {
        // 返回某對(duì)象某操作的接口函數(shù)，如dogUpdate
        return apiMap[obj][action]
    }
    // 返回一個(gè)包含多個(gè)操作接口函數(shù)的對(duì)象或公共接口
    return apiMap[obj]
}

// 封裝的接口
function obj1Func1(){}
function obj1Func2(){}
function obj2Func3(){}
function obj2Func4(){}

import API from 'xxx'
// 沒有錯(cuò)誤處理，主打看懂
async function getData() {
    const params = {...}
    const data = await API(obj1, 'get')(params)  
    await API(obj1, 'upd')(params)
    await API(obj1, 'del')(params)
}

import API from 'xxx'
const obj1API = API(obj1)

const data = await obj1API.get(params)  
const data = await obj1API.upd(params)  
const data = await obj1API.del(params)  

api函數(shù)

api函數(shù)可以復(fù)制或者寫在公共模塊引入就行了，實(shí)際上工作量只在維護(hù)映射表apiMap

現(xiàn)在查找接口原本一個(gè)模塊里可能涉及10個(gè)對(duì)象共100個(gè)接口，順序查找最差情況要看100條函數(shù)注釋，而根據(jù)對(duì)象查找最差情況是10（對(duì)象）+10（操作類型）即20條函數(shù)注釋。

const apiMap = {
    ...
    // 注釋：這是target對(duì)象
    targetObj: {
        add: objAddFunc, // 注釋：增刪改查的話可有可無
        upd: objUpdateFunc,
        del: objDeleteFunc,
        get: objGetFunc,
    }
    ...
}

這個(gè)場景有些理想化，但有一層封裝也確實(shí)能夠在需要時(shí)方便統(tǒng)一管理

然后這里?action: objActionFunc這里也算是一層封裝，方便進(jìn)行命名簡寫和規(guī)范

// xxxModule.js
const apiMap = {
    //對(duì)象1
    obj: {
        action: objActionFunc
        add: dogAdd,   // xxx/dog/add
        mAdd: dogImport,   // xxx/dog/import
        upd: dogUpdate,   // xxx/dog/update
    },
}

開發(fā)體驗(yàn)

和同事溝通后，我應(yīng)用在項(xiàng)目的一個(gè)模塊中，感覺很棒！

首先寫接口引入公共模塊的api函數(shù)，定義apiMap映射表，正常寫接口，工作量多了一個(gè)apiMap罷了

// 引入api，getType函數(shù)
import { api } from "common"
// api映射表
const apiMap = {
    ...
}
// 暴露api函數(shù)
export default api
// 封裝的接口
...

本文轉(zhuǎn)載于:

https://juejin.cn/post/7290558277666930744

如果對(duì)您有所幫助，歡迎您點(diǎn)個(gè)關(guān)注，我會(huì)定時(shí)更新技術(shù)文檔，大家一起討論學(xué)習(xí)，一起進(jìn)步。

?文章來源地址http://www.zghlxwxcb.cn/news/detail-715739.html