基于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方法，如文件操作，服务器信息等类*/exportclassBaseNormal {/**

        * 服务器请求的起始路径, 类似 '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的操作接口，如下所示。

/**

 * 服务器请求基础类*/exportclass 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>{



   ............./*其他接口定义*/}



exportdefault new SysMenuApi('/api/sysMenu');

对于没有标准CRUD接口的非常规API接口，我们可以让它继承NormalApi即可。

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

import { ConstOutput }from '/@/api/models';/**

 * 系统常量服务 管理Api*/
classSysConstApi extends BaseNormal {/**

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

    }

}



exportdefault 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 = awaitgetAPI(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 menuApifrom '/@/api/apis/sys-menu-api'

实际视图或者组件中的调用代码如下所示。

//查询操作
const handleQuery = async () =>{

    state.loading= true;var res = awaitmenuApi.list(state.queryParams);

    state.menuData= res.data.result ??[];

    state.loading= false;

};