基于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代码生成工具 进行了解。

 

posted on 2023-03-28 16:57  伍华聪  阅读(4977)  评论(5编辑  收藏  举报

导航