基于Admin.NET框架的前端的一些改进和代码生成处理（1）

始胖子 發表於 2023-3-28 16:57:00

基于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/，有兴趣可以分别到官网上进行预览了解。
<h3>1、API及对象接口的处理</h3>
一般的前端，为了访问后端接口，以及转换对象，都需要构建后端接口的API代理类，以及相关的对象接口定义，Admin.NET的前端这部分内容放在 api-services 目录下，包含了apis和models两个目录
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328160558240-1290244019.png" alt="" width="219" height="127" loading="lazy">
 不过由于它们可能使用基于类似  generator-swagger-2-ts 插件的方式进行前端代码的生成，因此代码显得非常臃肿，一个简单的API需要来回的封装接口进行调用，以字典API为例，每个API的类代码都显得很臃肿，接近1000行代码，这个和我们实际的API调用不太匹配，我们一般只需要简单的调用就可以做到了，太多的代码不利于阅读和维护。
在我的随笔《基于SqlSugar的开发框架循序渐进介绍（10）-- 利用axios组件的封装，实现对后端API数据的访问和基类的统一封装处理》中介绍过前端的API调用过程场景，如下所示。
<img src="https://img2020.cnblogs.com/blog/8867/202104/8867-20210427152546877-276221271.png" alt="" class="medium-zoom-image" loading="lazy">
前端一般根据框架后端的接口进行前端JS端的类的封装处理，引入了ES6类的概念实现业务基类接口的统一封装，简化代码。
一般我们在基类BaseApi中创建一些常用API的调用处理，那么常用的业务类继承BaseApi，就会具有相关的接口了，如下所示继承关系。
<img src="https://img2020.cnblogs.com/blog/8867/202007/8867-20200713152737929-890201160.png" alt="" class="medium-zoom-image" loading="lazy">
这样我们代码就会变得简洁很多，维护阅读都非常方便。
我们遵循Admin.NET的目录结构，如下所示放置Api接口和业务对象接口类。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328161609137-1226211726.png" alt="" width="342" height="140" loading="lazy">
 根据是否具有常规接口的后台接口定义，我们创建两个不同的基类BaseNormal 和 BaseApi ，这样我们便于实际的业务类Api的封装抽象。
如下是常规的基类，不具有任何基类接口，只是为了方便构造一些参数
<div class="cnblogs_code">
<pre>/**
* 此类作为普通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;
}
}</pre>
</div>
下面是一个具有数据访问CRUD的操作接口，如下所示。
<div class="cnblogs_code">
<pre>/**
* 服务器请求基础类
*/
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)
}
}</pre>
</div>
根据接口返回的内容，其中UnifyResult 对象接口是统一接口返回的处理对象，我们在types目录中定义即可，而SqlSugarPagedList则是Admin.NET分页返回的结果集合，这些基础类接口也是定义types目录中即可。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328162331550-1535318449.png" alt="" loading="lazy">
 <img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328162350888-1822370630.png" alt="" width="866" height="675" loading="lazy">
 而对于对应后端业务类对象接口的定义，我们倾向于把它按业务区分，一个业务类对应的放在一个独立的文件中定义即可，如下所示。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328162636455-1917509593.png" alt="" width="856" height="729" loading="lazy">
 一般包含一个标准的对象接口，增加对象、修改对象、查询对象等接口对象。
其中由于常规的业务对象接口，往往都具备一些基础的属性，因此我们把这些基础属性放到基类里面定义，然后在实际的业务对象接口中继承基类对象就可以了。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230329095517019-1940873318.png" alt="" width="856" height="938" loading="lazy">
 
 业务API代理类的定义，这是根据这些模型的信息进行简单的声明即可，如下对于菜单，如果不考虑除了增删改查的其他额外的接口，那么只需要简单的继承BaseApi即可。
<div class="cnblogs_code">
<pre>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');</pre>
</div>
对于没有标准CRUD接口的非常规API接口，我们可以让它继承NormalApi即可。
<div class="cnblogs_code">
<pre>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');</pre>
</div>
有了这些内容我们就可以在实际业务视图中进行API接口的调用了。
对于原先的Admin.NET的业务接口调用，他们需要先引入一个工厂类，然后构造处理才能调用接口，如下定义：
<div class="cnblogs_code">
<pre>import { getAPI } from '/@/utils/axios-utils';
import { SysMenuApi } from '/@/api-services/api';</pre>
</div>
原先的Admin.NET视图组件中的实际的调用代码如下所示。
<div class="cnblogs_code">
<pre>// 查询操作
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;
};</pre>
</div>
由于他们是采用Swagger的接口生成，因此默认接口名称都带有api的前缀，Get或者Post的后缀，感觉不是那么易读。
而对于我们重构过的处理逻辑，定义代码如下所示。
<div class="cnblogs_code">
<pre>import { SysMenu } from '/@/api/models';
import menuApi from '/@/api/apis/sys-menu-api'</pre>
</div>
实际视图或者组件中的调用代码如下所示。
<div class="cnblogs_code">
<pre>// 查询操作
const handleQuery = async () => {
state.loading = true;
var res = await menuApi.list(state.queryParams);
state.menuData = res.data.result ?? [];
state.loading = false;
};</pre>
</div>
实际调用代码简单只是一点点，但是Api的定义代码，从上千行调用代码则锐减到仅仅几行代码就可以了，减少了大量重复的累赘接口定义，以及很多模型接口重复定义操作（例如对于分页返回的对象，他们每次都生成一遍重读的类型，而这里则是使用泛型基于SqlSugarPagedList的方式进行简化）。
 
<h3>2、基于代码生成工具的生成</h3>
有些人说他们虽然代码多了一点，贵在能够根据接口自动生成前端代码呀，确实能自动生成代码是非常不错的一件事情，可以极大提高效率。
那么我们也根据接口的通用性，来构建代码生成的相关规则即可。由于这些接口的生成，大多数情况下，都是以数据库表和字段的规则进行生成的，因此我把它整合在代码生成工具的功能上生成即可。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328164253520-409937357.png" alt="" width="729" height="752" loading="lazy">
 <img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328164418167-1172020496.png" alt="" width="779" height="438" loading="lazy">
 <img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328164531665-729044419.png" alt="" width="774" height="682" loading="lazy">
最后我们把生成的Api部分代码放在目录中
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328164635230-964259944.png" alt="" loading="lazy">
 视图代码放在views目录里面对应的目录即可，如下是测试生成的页面，包括有index.vue 页面，以及edit.vue，以及import.vue的页面。
其中index是主页面查询及列表展示内容，edit.vue是新增和编辑界面内容，而import.vue这是导入界面内容。
目录文件如下图所示。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328164737780-1889460850.png" alt="" loading="lazy">
自动生成的index.vue页面代码，根据预定义的模板进行生成，经过多次的校准，已经比较完美的根据数据库表字段及备注信息，生成视图代码了。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328165534271-739775968.png" alt="" width="1213" height="1256" loading="lazy">
生成的页面，进行一定的微调即可用于实际的生产业务中了。 
该测试页面添加完成后，在后端创建一个菜单指向它即可，编译运行界面效果如下所示。
我改变了一下常规的界面功能，增加了导入、导出、批量删除的操作入口。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328165044442-2141615400.png" alt="" width="1112" height="336" loading="lazy">
 
 默认进行折叠，展开则列出所有条件，如下界面所示。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328165237626-2140439758.png" alt="" width="1075" height="299" loading="lazy">
 
导入界面是改进了ele-Import插件，得到界面效果如下所示。
<img src="https://img2023.cnblogs.com/blog/8867/202303/8867-20230328165354176-723771351.png" alt="" width="1050" height="542" loading="lazy">
 导出则是利用xlsx的插件进行导出Excel文件。 
 如果需要了解代码生成，可以下载Database2Sharp代码生成工具进行了解。
 

</div>
<div id="MySignature" role="contentinfo">
<div style="border-right-color: #cccccc; border-right-width: 1px; border-right-style: solid; padding-right: 5px; border-top-color: #cccccc; border-top-width: 1px; border-top-style: solid; padding-left: 4px; font-size: 13px; padding-bottom: 4px; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; width: 98%; padding-top: 4px; border-bottom-color: #cccccc; border-bottom-width: 1px; border-bottom-style: solid; background-color: #eeeeee;">
<img src="http://www.cnblogs.com/Images/OutliningIndicators/None.gif" align="top" alt>

专注于代码生成工具、.Net/Python 框架架构及软件开发，以及各种Vue.js的前端技术应用。著有Winform开发框架/混合式开发框架、微信开发框架、Bootstrap开发框架、ABP开发框架、SqlSugar开发框架、Python开发框架等框架产品。
 转载请注明出处：撰写人：伍华聪 http://www.iqidi.com </div> 
来源：https://www.cnblogs.com/wuhuacong/p/17265578.html

頁: [1]

琼殿技术论坛's Archiver

基于Admin.NET框架的前端的一些改进和代码生成处理（1）