做了這麼多年前端,為什麼你還是不會寫業務程式碼?

俗的太不一樣發表於2020-12-04

  我在平時工作中也會負責一些程式碼審查的工作,做的多了,就發現了一個問題:大部分程式設計師習慣把所有的邏輯都寫在vue檔案裡,所以這就導致一個問題,也就是你專案中的.vue檔案的程式碼會巨多,相反,你的js/ts檔案中的程式碼會沒有那麼多。如果是一個小型專案當然還好,如果是一個大型的專案,這可能就是維護人員的噩夢了,因為後續的維護成本是巨大的。至於為什麼,相信你看完這篇部落格就能懂我的意思了。

  今天有時間靜下心可以寫一篇部落格,總結了一下日常審過的程式碼,我們就用這些程式碼當作案例,分析一下我們以後的coding生涯該如何去避免這些問題。

  首先我們想思考一個問題:.vue檔案到底是用來幹嘛用的?

  我們可以看一下vue官網是如何介紹這款框架的:

image

  這個檢視層也就vm,說白了就是我們寫的頁面。

  那麼頁面中應該負責幹什麼呢?無非就是用htmlcss程式碼搭建頁面結構,然後頁面中可以能有一些元素的事件,比如說按鈕的點選事件,表單的查詢,表格的請求資料的動作等等。

  所以綜上所述我們可以總結一句話: .vue檔案中包含一些頁面結構以及頁面元素動作的發起。

  那麼,動作的發起者有了,動作的執行者是誰呢?

  我們看一些我們平常寫的專案結構是啥樣的,拿一個ts專案為例:

image

  這個是src下的目錄結構,應該是分的比較詳細的,各個資料夾有不同的作用,這也符合單一職責。

  我們在回過頭來看一些誰能當作動作的執行者呢?api只負責呼叫介面,他拿到資料後就丟擲了,資料這時候已經流向別處了,assets只放靜態資源,這兩個顯然不能。componentpublic_componentinstancemixinviews全是用來搭建頁面的,mixin雖然是ts檔案,但是他的定義也是可以分發Vue元件中的可複用功能,這些顯然也是不行的。interfaceutils這些是抽象出來的東西,顯然是不能放業務程式碼的。store現在已經不被大家看好了,因為vuex中的通訊實在是太繁瑣了,目前我們的專案只用來放一些字典資料用來快取。還剩下routersmiddlewarestyle這三個顯然不是幹這個用的。最後就只剩下domain了。

  domain(也有叫service的)作為業務層,我們給他最初的定義就是寫一些業務程式碼,按鈕的點選事件,頁面的滾動事件顯然不是業務程式碼,這些可以負責呼叫業務程式碼,也就是我們上面說的動作的發起者。這時候業務層的作用就來了,就是充當動作的執行者。設想一下,我點選一個按鈕去請求一個表格資料,那麼按鈕上肯定繫結一個click事件,點選完成之後就應該調介面了,後續的事情就可以交給業務層了,由業務層完成後續的邏輯,比如我拿資料需要呼叫api層先請求一下後臺資料,拿到資料看一下有沒有請求成功,資料是不是我們想要的格式,處理好時候就可以交給頁面層渲染了。

  好,我看一下實際的程式碼表現是什麼樣的。

  先說一個簡單需求,我們希望一個表格內展示一些使用者資料,看一下一般的程式設計師是怎麼做的:

資料結構:

    // 表格資料
    let tableData = [
        {
            date: "2016-05-02",
            name: "王小虎",
            address: "上海市普陀區金沙江路 1518 弄",
            phone: "13033443344",
            love: [
                '吃飯',
                '睡覺',
                '寫bug'
            ]
        },
         {
            date: "2016-05-02",
            name: "王小虎",
            address: "上海市普陀區金沙江路 1518 弄",
            phone: "13033443344",
            love: [
                '吃飯',
                '睡覺',
                '寫bug'
            ]
        }
        ...
    ]

   // 表頭資料

   let headData = [
        {
            label: "日期",
            prop: "date",
            width: "180"
        },
        {
            label: "姓名",
            prop: "name",
            width: "180"
        }
        ....
   ]

.vue檔案

<template>
    <div class="preivew-page">
        <el-table :data="tableData" style="width: 80%">
            <el-table-column v-for="(item, index) in headList" 
                        :key=index 
                        :prop="item.prop" 
                        :label="item.label" 
                        :width="item.width">
                <template slot-scope="scope" >
                    <span v-if="item.prop=='job'">{{scope.row.jobInfo.job}}</span>
                    <span v-else-if="item.prop=='love'">{{scope.row.love.join('-')}}</span>
                    <span v-else>{{scope.row[item.prop]}}</span>
                </template>
            </el-table-column>
        </el-table>
    </div>
</template>
<script lang='ts'>
import { Vue, Component } from "vue-property-decorator";
import { TableList } from "@/service/index";


@Component
export default class PreviewPage extends Vue {
    // 定義表格資料
    private tableData: any = [];
    // 定義表頭資料
    private headList: any = [];
    async mounted () {
        // 請求表格資料
        let tableList = new TableList();
        this.tableData = await tableList.searchTableData()
        this.headList = await tableList.searchHeadData()
    }
}
</script>

service業務層

import { getTableData, getHeadData } from "@/api/index"

export class TableList {
    public async searchTableData () {
        let data = await getTableData();
        return data;
    }

    public async searchHeadData () {
        let data = await getHeadData();
        return data;
    }
}

最終效果

image

  我們可以看出這裡的程式碼大部分寫在了.vue檔案中,裡邊包含了一些判斷和資料處理,而且業務層檔案基本沒發揮它的作用,只是簡單的呼叫了介面而已,我們知道一個類最基本的就是要構造他,才能體現它的多型,這裡只是一個頁面有表格業務操作,如果我們有很多個表格呢,是不是就會有很多個業務檔案?

  如果我們按照我的說法,把業務程式碼不寫在頁面而是寫在service中,看看是什麼效果:

.vue檔案

<template>
    <div class="preivew-page">
        <el-table :data="tableList.tableList" style="width: 80%">
            <el-table-column v-for="(item, index) in tableList.headList" 
                        :key=index 
                        :prop="item.prop" 
                        :label="item.label" 
                        :width="item.width">
            </el-table-column>
        </el-table>
    </div>
</template>
<script lang='ts'>
import { Vue, Component } from "vue-property-decorator";
import { TableList } from "@/service/index_two";
@Component
export default class PreviewPage extends Vue {
    // 表格業務
    private tableList: any = new TableList();
    async mounted () {
        // 請求表格資料
        await this.tableList.searchTableData()
        await this.tableList.searchHeadData()
    }
}
</script>

service業務層

import { getTableData, getHeadData } from "@/api/index"

export class TableList {
    // 表格資料
    public tableList: any;
    // 表頭資料
    public headList: any;

    constructor (tableList =[],headList=[]) {
        this.tableList = tableList;
        this.headList = headList;
    }

    public async searchTableData () {
        let data: any = await getTableData();
        this.tableList = data.map(el => {
            Reflect.set(el, 'job', el.jobInfo.job);
            Reflect.set(el, 'love', el.love.join('-'));
            return el
        })
    }

    public async searchHeadData () {
        this.headList = await getHeadData();
    }
}

  我們可以看出,業務類中定義了表格資料和表頭,從後端獲取到資料後直接掛在了業務類中,頁面那些資料處理也在放在了業務類中,在頁面中只需要把這個業務類存在vue例項中,在這個頁面中只要是需要就可以拿到這個業務中的屬性和方法。不僅如此,以後不管有多少個表格,只要是業務類似,都可以用這個業務類。是不是很方便?而且頁面中的程式碼減少了很多。個人認為這種方式是比第一種要好很多的。

  不僅如此,有沒有想過我們寫的form表單也是隻接寫成業務的?把每個表單中的欄位用類構造,這樣頁面中只接繫結類中的屬性。因為類是引用型別,所以頁面中表單有變化,業務類中是能響應的,這樣表單的查詢只接在類中取值就行了,而且表單構造相應變得簡單了很多。我們看一下這個例子:

service中的表單業務

export class Form {
    public job: string;
    public love: string[];
    public address: string;
    constructor ( job='', love=[], address='' ) {
        this.job = job;
        this.love = love;
        this.address = address
    }
}

.vue頁面

<template>
    <div class="preivew-page">
        ...
        <el-drawer title="表單"
                    :visible.sync="drawer"
                    direction="rtl">
            <el-form ref="form" :model="form" :inline="true" label-width="100px" size="mini">
                <el-form-item label="職位:">
                    <el-input v-model="form.job"></el-input>
                </el-form-item>
                <el-form-item label="愛好:">
                    <el-select v-model="form.love" multiple  placeholder="請選擇愛好">
                    <el-option label="吃飯" value="吃飯"></el-option>
                    <el-option label="睡覺" value="睡覺"></el-option>
                    <el-option label="打豆豆" value="打豆豆"></el-option>
                    <el-option label="寫bug" value="寫bug"></el-option>
                    </el-select>
                </el-form-item>
                <el-form-item label="地址:">
                    <el-input v-model="form.address"></el-input>
                </el-form-item>
            </el-form>
        </el-drawer>
    </div>
</template>
<script lang='ts'>
import { Vue, Component } from "vue-property-decorator";
import { Form } from "@/service/form"
@Component
export default class PreviewPage extends Vue {
    ...
    // 表單
    private form = new Form();

    openDialog () {
        this.drawer = true
    }

    // 點選表格中的編輯按鈕
    handleClick ( row: any ) {
        let { job,love,address } = row
        this.form = new Form(job,love,address);
        this.openDialog()
    }
}
</script>

  新增表單需要初始化資料,就是類構造的過程,點選編輯按鈕需要載入表格中的行資料,賦值到表單中,這時候需要拿到行資料再次構造一下業務類,是不是比賦值要方便很多,省去很多個等號?如果是個查詢的表單,那麼查詢的業務,重置的業務都可以在類中取完成。

  我們再深入研究一下,這個頁面中用到了側滑元件,想想我們在一個專案中是不是有很多個側滑,彈窗等等,那麼每次用都要寫一堆的開啟關閉這些事件嗎?其實這些簡單的邏輯不是我們重點關注的,如果我把這些流程寫成一個業務呢?看看下邊的程式碼:

.vue檔案

<template>
    <div class="preivew-page">
        <el-drawer title="表單"
                    :visible.sync="drawer.visible"
                    direction="rtl">
            ...
        </el-drawer>

        <el-button @click="drawer.open()">開啟</el-button>
        <el-button @click="drawer.close()">關閉</el-button>

    </div>
</template>
<script lang='ts'>
import { Vue, Component } from "vue-property-decorator";
import { Form } from "@/service/form";
import { Drawer } from "@/service/drawer"
@Component
export default class PreviewPage extends Vue {
    // 彈層控制
    private drawer = new Drawer()
    // 表單
    private form = new Form();
    handleClick ( row: any ) {
        let {job,love,address} = row
        this.form = new Form(job,love,address);
        this.drawer.open()
    }
}
</script>

service側滑業務

export class Drawer {
    public visible: boolean;

    constructor ( visible = false ) {
        this.visible = visible;
    }

    open () {
        this.visible = true;
    }

    close () {
        this.visible = false;
    }
}

  這樣每個側滑元件我們都可以用這個業務了;甚至像彈窗這種類似的元件也能用這個業務。

  其實看到這裡你應該就明白了,我們應該如何去寫業務程式碼了。

  我們作為程式設計師,從剛入行開始寫的就是業務程式碼,做的多了,應該學會自己把自己寫的程式碼變得更加漂亮了。老滿足於當下,不如搞點事情,寫一些優雅的程式碼。

  業務程式碼其實是最好寫的程式碼,只有業務程式碼寫的多了,我們才能明白如何將業務下沉為公共服務,公共服務再下沉為基礎服務,等到這時候,就不是寫業務程式碼這麼簡單了,他更考驗我們的抽象能力。

  本部落格耗時三天,就是希望大家不要老寫一些麵條程式碼,麵條程式碼是容易理解,但是那對我們的能力和技術一點不會有提升,只有善於封裝,善於優化才能寫出更加漂亮的程式碼。

關注我的個人部落格: 地址

我的開源專案: 地址

一天一句毒雞湯小程式

image

相關文章