基于Admin.NET框架的前端的一些改進和代碼生成處理（1）

Admin.NET 是一套基于Furion/.NET 6實作的通用管理平臺，模塊插件式開發，框架包含了常規的權限管理、字典等管理模塊，以及一些Vue3的Demo案例，框架前后端分離，后端基于基于Furion/.NET 6實作，底層集成SqlSugar；前端則是采用Vue-Next-Admin的前端框架，整體是一套非常不錯的框架，本人比較喜歡研究一些技術框架，最近對該框架進行了一些研究分析，結合我自己開發框架的思路，對其前后端進行一定的修改調整，本篇隨筆記錄一些對該框架的相關修改內容，

Admin.NET官網的的地址：https://gitee.com/zuohuaijun/Admin.NET，Vue-Next-Admin的官網地址：https://lyt-top.gitee.io/vue-next-admin-doc-preview/，有興趣可以分別到官網上進行預覽了解，

1、API及物件介面的處理

一般的前端，為了訪問后端介面，以及轉換物件，都需要構建后端介面的API代理類，以及相關的物件介面定義，Admin.NET的前端這部分內容放在 api-services 目錄 下，包含了apis和models兩個目錄

 不過由于它們可能使用基于類似  generator-swagger-2-ts 插件的方式進行前端代碼的生成，因此代碼顯得非常臃腫，一個簡單的API需要來回的封裝介面進行呼叫，以字典API為例，每個API的類代碼都顯得很臃腫，接近1000行代碼，這個和我們實際的API呼叫不太匹配，我們一般只需要簡單的呼叫就可以做到了，太多的代碼不利于閱讀和維護，

在我的隨筆《基于SqlSugar的開發框架循序漸進介紹（10）-- 利用axios組件的封裝，實作對后端API資料的訪問和基類的統一封裝處理》中介紹過前端的API呼叫程序場景，如下所示，

前端一般根據框架后端的介面進行前端JS端的類的封裝處理，引入了ES6類的概念實作業務基類介面的統一封裝，簡化代碼，

一般我們在基類BaseApi中創建一些常用API的呼叫處理，那么常用的業務類繼承BaseApi，就會具有相關的介面了，如下所示繼承關系，

這樣我們代碼就會變得簡潔很多，維護閱讀都非常方便，

我們遵循Admin.NET的目錄結構，如下所示放置Api介面和業務物件介面類，

 根據是否具有常規介面的后臺介面定義，我們創建兩個不同的基類BaseNormal 和 BaseApi ，這樣我們便于實際的業務類Api的封裝抽象，

如下是常規的基類，不具有任何基類介面，只是為了方便構造一些引數

/**
 * 此類作為普通API的基類，不繼承常規的通用CRUD方法，如檔案操作，服務器資訊等類
 */
export class BaseNormal {
    /**
        * 服務器請求的起始路徑, 類似 'http://localhost:**
       */
    protected basePath = serveConfig.basePath;

    /**
     * Api路徑，子類通過建構式修改, 其中api轉義為具體的路徑，如'/api/test'
    */
    protected apiPath = '/api/test';

    /**
     * 請求完整路徑（除了方法名），類似 `http://localhost:**\/api/test`
    */
    protected baseUrl = this.basePath + this.apiPath;//

    /**
     * 定義一個axios變數，便于子類訪問
    */
    protected axiosInstance = axiosInstance;

    /**
     * 建構式，接受Api路徑，如'/api/test'
    */
    constructor(apiPath: string) {
        // 建構式
        this.apiPath = apiPath;
        this.baseUrl = this.basePath + this.apiPath;
    }
}

下面是一個具有資料訪問CRUD的操作介面，如下所示，

/**
 * 服務器請求基礎類
*/
export class BaseApi<EntityType = any, AddType = any, UpdateType = any> extends BaseNormal {
    /**
     * 分頁獲取串列
    */
    page = async (data: object | null) => {
        const url = this.baseUrl + `/page`;
        return await this.axiosInstance.get<UnifyResult<SqlSugarPagedList<EntityType>>>(url, { params: data })
    }

    /**
     * 獲取串列
    */
    list = async (data: object | null) => {
        const url = this.baseUrl + `/list`;
        return await this.axiosInstance.get<UnifyResult<Array<EntityType>>>(url, { params: data })
    }

    /**
     * 新增記錄
    */
    add = async (data: AddType) => {
        const url = this.baseUrl + `/add`;
        return await this.axiosInstance.post<UnifyResult<void>>(url, data)
    }
    /**
     * 更新記錄
    */
    update = async (data: UpdateType) => {
        const url = this.baseUrl + `/update`;
        return await this.axiosInstance.post<UnifyResult<void>>(url, data)
    }
    /**
     * 洗掉記錄
    */
    delete = async (data: object) => {
        const url = this.baseUrl + `/delete`;
        return await this.axiosInstance.post<UnifyResult<void>>(url, data)
    }

    /** 批量洗掉 */
    batchDelete = async (data: object) => {
        const url = this.baseUrl + `/BatchDelete`;
        return await this.axiosInstance.post<UnifyResult<void>>(url, data)
    }
}

根據介面回傳的內容，其中UnifyResult 物件介面是統一介面回傳的處理物件，我們在types目錄中定義即可，而SqlSugarPagedList則是Admin.NET分頁回傳的結果集合，這些基礎類介面也是定義types目錄中即可，

 而對于對應后端業務類物件介面的定義，我們傾向于把它按業務區分，一個業務類對應的放在一個獨立的檔案中定義即可，如下所示，

 一般包含一個標準的物件介面，增加物件、修改物件、查詢物件等介面物件，

業務API代理類的定義，這是根據這些模型的資訊進行簡單的宣告即可，如下對于選單，如果不考慮除了增刪改查的其他額外的介面，那么只需要簡單的繼承BaseApi即可，

import { BaseApi } from './base-api';
import { SysMenu, UpdateMenuInput, AddMenuInput, MenuOutput } from '/@/api/models';

/**
 * 選單管理Api
 */
class SysMenuApi extends BaseApi<SysMenu, AddMenuInput, UpdateMenuInput> {

   ............./*其他介面定義*/

}

export default new SysMenuApi('/api/sysMenu');

對于沒有標準CRUD介面的非常規API介面，我們可以讓它繼承NormalApi即可，

import { BaseNormal} from './base-api';
import { ConstOutput } from '/@/api/models';

/**
 * 系統常量服務 管理Api
 */
class SysConstApi extends BaseNormal {  

     /**
     * 獲取所有常量串列
    */
     list = async () => {
        const url = this.baseUrl + `/list`;
        return await this.axiosInstance.get<UnifyResult<Array<ConstOutput>>>(url, { params: null })
    }
}

export default new SysConstApi('/api/sysConst');

有了這些內容我們就可以在實際業務視圖中進行API介面的呼叫了，

對于原先的Admin.NET的業務介面呼叫，他們需要先引入一個工廠類，然后構造處理才能呼叫介面，如下定義：

import { getAPI } from '/@/utils/axios-utils';
import { SysMenuApi } from '/@/api-services/api';

原先的Admin.NET視圖組件中的實際的呼叫代碼如下所示，

// 查詢操作
const handleQuery = async () => {
    state.loading = true;
    var res = await getAPI(SysMenuApi).apiSysMenuListGet(state.queryParams.title, state.queryParams.type);
    state.menuData = res.data.result ?? [];
    state.loading = false;
};

由于他們是采用Swagger的介面生成，因此默認介面名稱都帶有api的前綴，Get或者Post的后綴，感覺不是那么易讀，

而對于我們重構過的處理邏輯，定義代碼如下所示，

import { SysMenu } from '/@/api/models';
import menuApi from '/@/api/apis/sys-menu-api'

實際視圖或者組件中的呼叫代碼如下所示，

// 查詢操作
const handleQuery = async () => {
    state.loading = true;
    var res = await menuApi.list(state.queryParams);
    state.menuData = res.data.result ?? [];
    state.loading = false;
};

實際呼叫代碼簡單只是一點點，但是Api的定義代碼，從上千行呼叫代碼則銳減到僅僅幾行代碼就可以了，減少了大量重復的累贅介面定義，以及很多模型介面重復定義操作（例如對于分頁回傳的物件，他們每次都生成一遍重讀的型別，而這里則是使用泛型基于SqlSugarPagedList的方式進行簡化），

2、基于代碼生成工具的生成

有些人說他們雖然代碼多了一點，貴在能夠根據介面自動生成前端代碼呀，確實能自動生成代碼是非常不錯的一件事情，可以極大提高效率，

那么我們也根據介面的通用性，來構建代碼生成的相關規則即可，由于這些介面的生成，大多數情況下，都是以資料庫表和欄位的規則進行生成的，因此我把它整合在代碼生成工具的功能上生成即可，

最后我們把生成的Api部分代碼放在目錄中

 視圖代碼放在views目錄里面對應的目錄即可，如下是測驗生成的頁面，包括有index.vue 頁面，以及edit.vue，以及import.vue的頁面，

其中index是主頁面查詢及串列展示內容，edit.vue是新增和編輯界面內容，而import.vue這是匯入界面內容，

目錄檔案如下圖所示，

自動生成的index.vue頁面代碼，根據預定義的模板進行生成，經過多次的校準，已經比較完美的根據資料庫表欄位及備注資訊，生成視圖代碼了，

生成的頁面，進行一定的微調即可用于實際的生產業務中了， 

該測驗頁面添加完成后，在后端創建一個選單指向它即可，編譯運行界面效果如下所示，

我改變了一下常規的界面功能，增加了匯入、匯出、批量洗掉的操作入口，

 默認進行折疊，展開則列出所有條件，如下界面所示，

匯入界面是改進了ele-Import插件，得到界面效果如下所示，

 匯出則是利用xlsx的插件進行匯出Excel檔案， 

 如果需要了解代碼生成，可以下載Database2Sharp代碼生成工具 進行了解，

標籤：其他

上一篇：vue全家桶進階之路23：Element UI

下一篇：JavaScript實作檔案上傳demo