2023年2月

在做一些常规应用的时候,我们往往需要确定条件的内容,以便在后台进行区分的进行精确查询,在移动端,由于受限于屏幕界面的情况,一般会对多个指定的条件进行模糊的搜索,而这个搜索的处理,也是和前者强类型的条件查询处理类似的处理过程,因此本篇随笔探讨两种不同查询在前端界面上的展示效果,以及后端基于.netCore的Web API端的基类进行的统一封装处理。

1、前端精确条件的查询处理

在基于Vue3+Typescript+ElementPlus的前端界面中,查询是很多界面需要拥有的功能,如下所示。

展开后的全部查询条件

以上的查询部分是一个查询函数的处理,如下代码所示。

//查询列表处理
async functionsearch() {
pageInfo.pageIndex
= 1; //重置为第一页 //默认使用当前用户公司 const userInfo = $u.util.storageSession.getItem('user_info');
searchForm.company_ID
= userInfo?.company_ID; //所属公司 await getlist(); //获取列表 }//列表数据获取 async functiongetlist() {
loading.value
= true;var param ={//分页条件 SkipCount: (pageInfo.pageIndex - 1) *pageInfo.pageSize,
MaxResultCount: pageInfo.pageSize,
Sorting: sorting.value,
//查询过滤条件 Name: searchForm.name,
MobilePhone: searchForm.mobilePhone,
Email: searchForm.email,
QQ: searchForm.qq,
Nickname: searchForm.nickname,
HandNo: searchForm.handNo,
IsExpire: searchForm.isExpire,
Title: searchForm.title,

dept_ID: searchForm.dept_id,
company_ID: searchForm.company_ID
};
//日期条件处理 addDateRange(param, searchForm.creationTime);

let result
=await user.GetList(param);if(result) {
list.value
=result.items;
pageInfo.totalCount
=result.totalCount;
}

setTimeout(()
=>{
loading.value
= false;
},
500);
}

我们看到,这些条件都是由特定的参数组成的,因此他们是精确性的属性查询。

前端根据框架后端的接口进行前端JS端的类的封装处理,引入了ES6类的概念实现业务基类接口的统一封装,简化代码。

权限模块我们涉及到的用户管理、机构管理、角色管理、菜单管理、功能管理、操作日志、登录日志等业务类,那么这些类继承BaseApi,就会具有相关的接口了,如下所示继承关系。

按照这个思路,我们在BaseApi的ES6类里面定义了对应Web API基类里面的操作方法,如下所示。

这样,我们在创建一个业务类的时候,如果没有特殊的自定义接口,只需要继承基类BaseApi即可具有所有的常规基类方法了。

我们再来后端看看具体的查询逻辑实现,首先需要了解各个控制器之间的继承关系,如下图所示 。

同样,我们基础的查询处理逻辑,主要也是放在BusinessController里面实现,毕竟是通用的逻辑,变化的只是一些实体信息,因此可以通过泛型的模板方法设计模式处理变化的部分。

我们可以看到,在BusinessController控制器部分,它也只是对Service层逻辑的简单封装一下,核心的处理逻辑部分,在下面的基类Service层的代码中。

/// <summary>
///根据条件获取列表/// </summary>
/// <param name="input">分页查询条件</param>
/// <returns></returns>
public virtual async Task<PagedResultDto<TEntity>>GetListAsync(TGetListInput input)
{
var query =CreateFilteredQueryAsync(input);var totalCount = awaitquery.CountAsync();

query
=ApplySorting(query, input);
query
=ApplyPaging(query, input);var list = awaitquery.ToListAsync();return new PagedResultDto<TEntity>(
totalCount,
list
);
}

这里基类Service层主要处理逻辑部分,而具体的构建精确的查询处理条件,下放在了每个具体业务Service类中进行处理了。

UserService是具体对应的业务类的逻辑处理层,该类的定义方法如下所示。

    /// <summary>
    ///应用层服务接口实现/// </summary>
    public class UserService : MyCrudService<UserInfo, int, UserPagedDto>, IUserService

下放在UserService这个具体业务的Service类中的查询处理逻辑,这部分通过代码生成工具生成即可。

/// <summary>
///自定义条件处理/// </summary>
/// <param name="input">查询条件Dto</param>
/// <returns></returns>
protected override ISugarQueryable<UserInfo>CreateFilteredQueryAsync(UserPagedDto input)
{
var query = base.CreateFilteredQueryAsync(input);
query
=query
.WhereIF(input.ExcludeId.HasValue, t
=> t.Id != input.ExcludeId) //不包含排除ID .WhereIF(input.PID.HasValue, s => s.PID ==input.PID)
.WhereIF(
!input.HandNo.IsNullOrWhiteSpace(), t => t.HandNo.Contains(input.HandNo)) //如需要精确匹配则用Equals .WhereIF(!input.Name.IsNullOrWhiteSpace(), t => t.Name.Contains(input.Name)) //如需要精确匹配则用Equals .WhereIF(!input.FullName.IsNullOrWhiteSpace(), t => t.FullName.Contains(input.FullName)) //如需要精确匹配则用Equals .WhereIF(!input.Nickname.IsNullOrWhiteSpace(), t => t.Nickname.Contains(input.Nickname)) //如需要精确匹配则用Equals .WhereIF(input.IsExpire.HasValue, t => t.IsExpire == input.IsExpire) //如需要精确匹配则用Equals//过期时间区间查询 .WhereIF(input.ExpireDateStart.HasValue, s => s.ExpireDate >=input.ExpireDateStart.Value)
.WhereIF(input.ExpireDateEnd.HasValue, s
=> s.ExpireDate <=input.ExpireDateEnd.Value)****//此处省略更多其他条件 ;returnquery;
}

通过逻辑和具体对象的实现分离,从而构建了很多通用的基类函数,这些函数只需要在子类重写一些规则即可实现更加详细的处理,也称为模板方法的设计模式,这种方式广泛应用于基类函数的抽象处理。

2、前端模糊查询及自定义查询的处理

介绍了前面基于Vue3+Typescript+ElementPlus的前端界面的内容,主要还是用来引出基于UniApp+Vue的移动端实现多条件查询的处理,一般移动端的界面空间比较宝贵,所以往往查询通过组合条件的方式进行模糊查询处理,如下界面所示。

在查询框中输入一些条件,会在后端对多个条件进行模糊匹配,并返回相应的结果列表进行展示,如下所示。

查询界面只是接受了一个输入值,通过传递该值,在后端进行多字段的匹配查询处理。前端界面如下所示。

async getlist() {var params ={
MaxResultCount:
this.pageSize,
SkipCount: (
this.pageIndex - 1) * this.pageSize,
Sorting:
'',
}
if (this.isAdvance) {
let {
startDate,
endDate,
filter,
deliveryArea,
line
}
= this.advanceData;
params.TimeStart
=startDate
params.TimeEnd
=endDate
params.DeliveryAreas
=deliveryArea
params.Lines
=line
params.Filter
=filter
}
else{
params.Filter
= this.searchValue;
}
console.log(params)
this.loadding = true;this.pullUpOn = true;

let res
={};if (this.isAdvance) {
res
=await sign.GetAllByFilter2(params);
}
else{
res
=await sign.GetAllByFilter(params);
}
console.log(res)
if (this.totalCount ==res.totalCount) {this.hasmore = false; //没有了 this.loadding = false;this.pullUpOn = false;
uni.stopPullDownRefresh();
return;
}
this.totalCount =res.totalCount;
let items
=res.items;for (var i = 0; i < items.length; i++) {this.list.push(items[i]);
}
if (this.list.length <res.totalCount) {this.pageIndex += 1;
console.log(res.totalCount)
}
else{this.hasmore = false; //没有了 }this.loadding = false;this.pullUpOn = falseuni.stopPullDownRefresh();

let count
=items.length;
let options
={
msg: `刷新成功,为你更新了${count}条数据`,
duration:
2000,
type:
"translucent"};if (this.pageIndex > 1) {
setTimeout(()
=>{this.$refs.toast.showTips(options);
},
300);
}
},

有时候,如需要精确一些的条件处理,也可以以自定义条件的方式进行查询处理的界面。

单击【筛选】按钮进入抽屉式的展示页面,弹出高级查询的相关字段属性,可以进行一定的条件设置处理。

同样我们在UniApp+Vue的移动前端项目上,也需要设置BaseApi的基础接口,如下所示。

而我们的业务类 Sign-Receipt(Sign-Receipt.js )只需要继承BaseApi(base-api.js)类即可,如下所示。

import BaseApi from '@/api/base-api'

//业务类自定义接口实现, 通用的接口已经在BaseApi中定义
class Api extends BaseApi {
FindByCode(shopCode) {
//GET 根据客户代码获取记录 var params ={
shopCode
};
return this.httpget(this.baseurl + 'Find-ByCode', params)
}

GetAllByFilter2(params) {
//根据条件获取所有记录 var url = this.baseurl + 'list-filter2';return this.httpget(url, params)
}
}
//构造接口对象信息 Api实例,并传递业务类接口地址 export default new Api('/api/SignReceipt/')

对应的后端接口,同样也是使用前面介绍精确查询的方式进行处理,在基类Service层里面,有对应通用的模糊查询方法定义。

/// <summary>
///根据指定的Filter值分页获取列表/// </summary>
/// <param name="input">分页查询条件</param>
/// <returns></returns>
public virtual async Task<PagedResultDto<TEntity>>GetListByFilterAsync(PagedSortedAndFilteredInputDtoinput)
{
var query =CreateFilteredQueryAsync(input.Filter);var totalCount = awaitquery.CountAsync();//排序处理 if (!input.Sorting.IsNullOrWhiteSpace())
{
query
=query.OrderBy(input.Sorting);
}
else{
query
=ApplyDefaultSorting(query);
}
//分页处理 query =query.Skip(input.SkipCount).Take(input.MaxResultCount);var list = awaitquery.ToListAsync();return new PagedResultDto<TEntity>(
totalCount,
list
);
}

那么下放给子类的
CreateFilteredQueryAsync
函数就是实现逻辑的关键,毕竟基类是无法构建正确的条件的。

而对应的SignReceiptService类中,是业务类的逻辑处理方法,该类的定义方法如下所示

    /// <summary>
    ///拍照签收 应用层服务接口实现/// </summary>
    public class SignReceiptService : MyCrudService<SignReceiptInfo,string, SignReceiptPagedDto>, ISignReceiptService

因此它里面可以重写模糊查询条件的逻辑,如下代码所示。

/// <summary>
///自定义条件处理(根据Filter进行的过滤处理)/// </summary>
/// <param name="filter">查询条件Dto</param>
/// <returns></returns>
protected override ISugarQueryable<SignReceiptInfo> CreateFilteredQueryAsync(stringfilter)
{
var query = base.CreateFilteredQueryAsync(filter);
query
= query.WhereIF(!filter.IsNullOrWhiteSpace(), t => //模糊搜索用Contains, 如需要精确匹配则用Equals t.ShopCode.Contains(filter) || t.ShopName.Contains(filter) || t.Line.Contains(filter) ||t.DeliveryArea.Contains(filter)|| t.SignMan.Contains(filter) || t.DeliverName.Contains(filter) ||t.Note.Contains(filter)
);
returnquery;
}

有了这些条件的定义,我们就可以在Web API的后端,对前端的参数进行联合的模糊查询处理,从而为移动前端提供更好的查询接口服务。

而对于高级查询的处理,我们先要定义好对应的通用的实体类信息,如下所示。

然后在具体的进行处理查询逻辑即可,这部分和前面的逻辑处理类似,只是无法实现基类通用的处理而已,因此下发到具体的业务类进行定义。

最后在控制器部分,进行一个简单的封装处理即可。

以上就是基于不同前端,包括基于Vue3+Typescript+ElementPlus的前端界面,以及基于UniApp+Vue的移动端界面,实现一些常见查询的处理,前端和后端的配合处理逻辑。

系列文章:


基于SqlSugar的开发框架的循序渐进介绍(1)--框架基础类的设计和使用


基于SqlSugar的开发框架循序渐进介绍(2)-- 基于中间表的查询处理


基于SqlSugar的开发框架循序渐进介绍(3)-- 实现代码生成工具Database2Sharp的整合开发


基于SqlSugar的开发框架循序渐进介绍(4)-- 在数据访问基类中对GUID主键进行自动赋值处理


基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接口注入方式实现IOC控制反转


基于SqlSugar的开发框架循序渐进介绍(6)-- 在基类接口中注入用户身份信息接口


基于SqlSugar的开发框架循序渐进介绍(7)-- 在文件上传模块中采用选项模式【Options】处理常规上传和FTP文件上传


基于SqlSugar的开发框架循序渐进介绍(8)-- 在基类函数封装实现用户操作日志记录


基于SqlSugar的开发框架循序渐进介绍(9)-- 结合Winform控件实现字段的权限控制


基于SqlSugar的开发框架循序渐进介绍(10)-- 利用axios组件的封装,实现对后端API数据的访问和基类的统一封装处理


基于SqlSugar的开发框架循序渐进介绍(11)-- 使用TypeScript和Vue3的Setup语法糖编写页面和组件的总结


基于SqlSugar的开发框架循序渐进介绍(12)-- 拆分页面模块内容为组件,实现分而治之的处理


基于SqlSugar的开发框架循序渐进介绍(13)-- 基于ElementPlus的上传组件进行封装,便于项目使用


基于SqlSugar的开发框架循序渐进介绍(14)-- 基于Vue3+TypeScript的全局对象的注入和使用


基于SqlSugar的开发框架循序渐进介绍(15)-- 整合代码生成工具进行前端界面的生成


基于SqlSugar的开发框架循序渐进介绍(16)-- 工作流模块的功能介绍


基于SqlSugar的开发框架循序渐进介绍(17)-- 基于CSRedis实现缓存的处理


基于SqlSugar的开发框架循序渐进介绍(18)-- 基于代码生成工具Database2Sharp,快速生成Vue3+TypeScript的前端界面和Winform端界面


基于SqlSugar的开发框架循序渐进介绍(19)-- 基于UniApp+Vue的移动前端的功能介绍


基于SqlSugar的开发框架循序渐进介绍(20)-- 在基于UniApp+Vue的移动端实现多条件查询的处理

有时候,为了给前端页面输出内容,有时候我们需要准备和数据库不一样的实体信息,因为数据库可能记录的是一些引用的ID或者特殊字符,那么我们为了避免前端单独的进行转义处理,我们可以在后端进行统一的格式化后再行输出,后端处理可以采用不同的DTO尸体信息,后端对不同的实体进行映射处理即可,也可以采用同一个实体,在SqlSugar实体信息中忽略对应的字段写入实现,本篇随笔介绍后者的处理方式,实现在在工作流列表页面中增加一些转义信息的输出处理。

1、后端的转义处理

大多数页面,我们的前端显示信息DTO和后端的数据库实体信息Entity是一致的,只有部分信息的差异,特别在工作流模块中,由于继承原来历史的数据库设计结构,因此很多引用的字段是int类型的,那么为了避免前端对内容的频繁解析,因此必要的时候在后端对内容进行统一的处理,实现内容的转义。

例如我们以其中的模板流程的实体信息定义来看,除了对常规的信息,我们还需要对一些转义信息的处理。

如实体类对应字段的SqlSugar的标识,只需要增加SqlsugarColumn的标识即可。

        [SqlSugar.SugarColumn(ColumnName = "PROC_TYPE")]public virtual int ProcType { get; set; }

如下所示的实体类

如果我们需要额外增加一些信息的承载,而在保存或者提取数据库字段信息的时候,进行忽略处理,那么标识为Ignor即可。

        [SqlSugar.SugarColumn(IsIgnore = true)]public virtual string ProcTypeName { get; set; }

如下实体类代码所示

有了实体信息的定义,我们在SqlSurgar框架的服务层返回列表信息的时候,可以对列表的内容进行统一的转换,而列表返回是在基类定义的统一泛型函数,如下定义所示。

        /// <summary>
        ///根据条件获取列表/// </summary>
        /// <param name="input">分页查询条件</param>
        /// <returns></returns>
        public virtual async Task<PagedResultDto<TEntity>>GetListAsync(TGetListInput input)
{
var query =CreateFilteredQueryAsync(input);var totalCount = awaitquery.CountAsync();

query
=ApplySorting(query, input);
query
=ApplyPaging(query, input);var list = awaitquery.ToListAsync();return new PagedResultDto<TEntity>(
totalCount,
list
);
}

因此需要在继承的子类中重写一下进行处理,如下代码所示。

而对于附加信息的多少,则根据我们的业务规则适当调整即可,有些实体信息附加的内容可能会多一些,有些会少一些,有些可能保存原状即可。

2、前端的列表显示

介绍了后端的内容转义,前端相对处理就比较简单了,只需要把对应的内容进行显示即可。如前端的Vue3+TypeScript+ElementPlus的代码如下。

<!--表格列表信息-->
<el-tablev-loading="loading":data="list"border
fit
stripe
highlight-current-row
:header-cell-style
="{ background: '#eef1f6', color: '#606266' }"@selection-change="selectionChange"@row-dblclick="rowDbclick"@sort-change="sortChange" > <el-table-columntype="selection"width="40" /> <el-table-columnalign="center"sortable="custom"prop="proc_Name"label="流程环节名称"> <templatev-slot="scope">{{ scope.row.procName }}</template> </el-table-column> <el-table-columnalign="center"sortable="custom"prop="proc_Type"label="处理类型"> <templatev-slot="scope">{{ scope.row.procTypeName}}</template> </el-table-column> <el-table-columnalign="center"sortable="custom"prop="form_ID"label="对应表单"> <templatev-slot="scope">{{ scope.row.formName ?? '所有表单' }}</template> </el-table-column>

js代码也只需简单的获取对应list的分页列表即可。前端没有额外增加工作量。

工作流部分转义页面显示效果如下所示。

系列文章:


基于SqlSugar的开发框架的循序渐进介绍(1)--框架基础类的设计和使用


基于SqlSugar的开发框架循序渐进介绍(2)-- 基于中间表的查询处理


基于SqlSugar的开发框架循序渐进介绍(3)-- 实现代码生成工具Database2Sharp的整合开发


基于SqlSugar的开发框架循序渐进介绍(4)-- 在数据访问基类中对GUID主键进行自动赋值处理


基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接口注入方式实现IOC控制反转


基于SqlSugar的开发框架循序渐进介绍(6)-- 在基类接口中注入用户身份信息接口


基于SqlSugar的开发框架循序渐进介绍(7)-- 在文件上传模块中采用选项模式【Options】处理常规上传和FTP文件上传


基于SqlSugar的开发框架循序渐进介绍(8)-- 在基类函数封装实现用户操作日志记录


基于SqlSugar的开发框架循序渐进介绍(9)-- 结合Winform控件实现字段的权限控制


基于SqlSugar的开发框架循序渐进介绍(10)-- 利用axios组件的封装,实现对后端API数据的访问和基类的统一封装处理


基于SqlSugar的开发框架循序渐进介绍(11)-- 使用TypeScript和Vue3的Setup语法糖编写页面和组件的总结


基于SqlSugar的开发框架循序渐进介绍(12)-- 拆分页面模块内容为组件,实现分而治之的处理


基于SqlSugar的开发框架循序渐进介绍(13)-- 基于ElementPlus的上传组件进行封装,便于项目使用


基于SqlSugar的开发框架循序渐进介绍(14)-- 基于Vue3+TypeScript的全局对象的注入和使用


基于SqlSugar的开发框架循序渐进介绍(15)-- 整合代码生成工具进行前端界面的生成


基于SqlSugar的开发框架循序渐进介绍(16)-- 工作流模块的功能介绍


基于SqlSugar的开发框架循序渐进介绍(17)-- 基于CSRedis实现缓存的处理


基于SqlSugar的开发框架循序渐进介绍(18)-- 基于代码生成工具Database2Sharp,快速生成Vue3+TypeScript的前端界面和Winform端界面


基于SqlSugar的开发框架循序渐进介绍(19)-- 基于UniApp+Vue的移动前端的功能介绍


基于SqlSugar的开发框架循序渐进介绍(20)-- 在基于UniApp+Vue的移动端实现多条件查询的处理

在工作流页面中,除了特定的业务表单信息外,往往也需要同时展示通用申请单的相关信息,因此在页面设计的时候需要使用一些组件化的概念来实现动态的内容展示处理,本篇随笔介绍Vue3+TypeScript+ElementPus的前端工作流模块中实现统一的表单编辑和表单详情查看处理。

1、查看申请单的模块设计处理

在工作流处理表中,首先我们区分流程模板和流程实例两个部分,这个其实就是类似模板和具体文档的概念,我们一份模板可以创建很多个类似的文档,文档样式结构类似的。同理,流程模板实例为流程实例后,就是具体的一个流程表单信息了,其中流程模板和流程实例表单都包括了各个流程步骤。在流程实例的层次上,我们运行的时候,需要记录一些日志方便跟踪,如流程步骤的处理日志,流程实例表单的处理日志等这些信息。

一旦流程实例根据模板创建后,流程先根据模板初始化后,在处理过程还可以动态增加一些审批步骤,使得我们的处理更加弹性化。

当然,为了更好的处理流程的相关信息,还需要记录流程处理人,流程会签人、流程阅办人,以及常用审批意见等相关辅助表,以便对流程的各个处理信息进行合理处理和展示。

对于一个流程处理操作,我们知道一般有审批通过、拒绝、退回到某步骤、转发到内部阅读、阅读,以及包括起草者能撤销表单呢等操作,当然如果还有一些具体的业务,可能还会有一些流程的处理才操作,不过基本上也可以归结为上面几种,只是他们每步处理的数据内容不同而已。因此审批的操作步骤分类如下所示。

在基于 Vue3+TypeScript+ElementPus的前端工作流模块中,我们在查看表单明细的时候,需要包含公用表单信息,特定表单信息两部分内容。前者表单数据可以统一呈现,而后者则是不同业务的表单数据不同。为了实现更好的维护性,把它们分开作为两部分处理,但是页面入口设计为统一的呈现页面。

表单数据按内容区分分为了两类:通用业务表单、特定业务表单

如果我们要把两者统一在一个通用页面中进行展示,就需要根据不同表单名称,动态加载属于特定表单的展示模块,也就是动态组件的实现方式,大概的业务规则如下所示。

页面效果如下图所示。

而编辑界面也是类似,通过动态化组件的方式合并公用信息和特定表单组件信息。

2、查看、编辑页面路由设置及项目视图目录

通过动态化组件的呈现处理,可以实现编辑和查看申请单页面的动态呈现,我们Vue的前端也可以只需要定义一个查看页面路由,和一个编辑界面的路由即可,极大的降低开发代码和复杂度。如下面是路由的JSON文件中关于查看、编辑页面的路由信息。

在 Vue3+TypeScript+ElementPus的前端项目中,我们创建了几个不同的目录来放置不同的页面代码,如edit是编辑特定表单的组件页面目录,view是查看特定表单的组件页面目录,list则是该表单的详细列表信息,而system工作流系统的管理页面等等,如下图所示。

其中Edit、View目录下,都是对应表单名称的页面组件(页面代码)

在通用的查看表单页面中,我们定义了两个部分的内容,包括公用处理单的信息,以及特定表单的信息展示,如下代码所示。

而特定表单的内容展示,这是通过动态化组件的呈现方式(is)来指定具体渲染的那个页面组件

而通用的申请单编辑页面中,则是动态展示编辑对应组件页面的信息即可,如下所示。

而动态组件的处理,我们使用vue3的
defineAsyncComponent
(需要了解可以查看官网)的处理方式进行加载对应组件页面。

我们在ts的setup代码块中的代码如下所示。

let viewType = ref(null); //查看明细的组件类型

//根据申请单的模块类型定义,确定组件名称
functiongetViewType() {if(applyid.value) {//一般规则:通过申请单的DataTable去掉前缀,转换小写,获得模块名称,如TW_Payment => payment
    var param ={ applyId: applyid.value };
apply.GetModuleName(param).then(data
=>{if(data) {
console.log(data);
let pageComponent
= defineAsyncComponent(() => import(`/@/views/workflow/modules/view/${data.toLowerCase()}.vue`));//console.log(pageComponent); viewType.value =markRaw(pageComponent);
}
});
}
}

而其中viewType就是我们组件的名称,这里能够呈现出来的内容,必须是这些组件在对应的工作流目录中的,通过动态的加载方式,可以实现页面组件的动态渲染处理了。

而我们定义的表单内容可能很多,如下目录所示。

其中我们以报销申请单的查看页面来了解,页面展示部分如下代码所示。

      <el-formref="viewRef":model="viewForm"label-width="120px">
        <el-tabstype="border-card">
          <el-tab-panelabel="基本信息">
            <el-descriptionstitle="":column="2"border>
              <el-descriptions-itemlabel="报销类型">{{ viewForm.category }}</el-descriptions-item>
              <el-descriptions-itemlabel="报销事由">{{ viewForm.reason }}</el-descriptions-item>
              <el-descriptions-itemlabel="总金额">
                <el-inputv-model="viewForm.totalAmount"disabled style="width: 150px">
                  <template#suffix></template>
                </el-input>
              </el-descriptions-item>
              <el-descriptions-itemlabel="备注信息":span="2">{{ viewForm.note }}</el-descriptions-item>
              <el-descriptions-itemlabel="明细清单":span="2">
                <vxe-tableref="xTable"stripe highlight-current-row highlight-hover-row :data="detailData">
                  <vxe-columntype="seq"width="60" />
                  <vxe-columnfield="feeType"title="费用类型"width="100" />
                  <vxe-columnfield="occurTime"title="发生时间"width="250" />
                  <vxe-columnfield="feeAmount"title="费用金额"width="100" />
                  <vxe-columnfield="feeDescription"title="费用说明"width="250" />
                </vxe-table>
              </el-descriptions-item>
              <el-descriptions-itemlabel="附件":span="2">
                <my-uploadv-model="viewForm.attachGUID":disabled="true":data="{ guid: viewForm.attachGUID, folder: '申请单图片' }" />
              </el-descriptions-item>
            </el-descriptions>
          </el-tab-pane>
        </el-tabs>
      </el-form>

主从表的数据,我们通过函数来实现加载处理,而后端对应提供相关的数据结构即可。

//挂载的时候初始化数据
onMounted(async () =>{
await getData();
//打开新增窗体的时候,初始化公司列表 });functiongetData() {
let applyid
= props.applyid + '';if(applyid) {
reimbursement.FindByApplyId(applyid).then(data
=>{
Object.assign(viewForm, data);
//获取从表明细记录 var headerId =viewForm.id;
reimbursement.FindDetailByHeaderId(headerId).then(data
=>{
detailData.value
=data;
});
});
}
}

对于审批,我们提供一些通过、退回、取消的申请单处理操作。

审批表单的界面

发起会签操作界面

撤销自己表单的处理界面

由于申请单的各种类型节点的处理不同,如果页面引入这些会显得很臃肿,因此我们把这些处理步骤组件化,然后再通过查看页面中整合审批、发起会签、会签、批示阅办、撤销、阅办等操作即可。

这样我们把一些常用节点的处理,单独作为组件开发,放置在组件目录中即可,方便维护。

Vue的组件化,可以简化页面的内容处理,把特定的部分放在一个组件中实现,更好的实现关注点的分离,以及可以自由组合更好的页面效果。

而为了方便,特定处理单的列表页面,我们也提供了查询展示的处理,便于跟踪查询对应类型的业务表单信息。

以上就是对于 Vue3+TypeScript的前端工作流模块中实现统一的表单编辑和表单详情查看处理的一些总结,希望对您有所启发和帮助。

系列文章:


基于SqlSugar的开发框架的循序渐进介绍(1)--框架基础类的设计和使用


基于SqlSugar的开发框架循序渐进介绍(2)-- 基于中间表的查询处理


基于SqlSugar的开发框架循序渐进介绍(3)-- 实现代码生成工具Database2Sharp的整合开发


基于SqlSugar的开发框架循序渐进介绍(4)-- 在数据访问基类中对GUID主键进行自动赋值处理


基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接口注入方式实现IOC控制反转


基于SqlSugar的开发框架循序渐进介绍(6)-- 在基类接口中注入用户身份信息接口


基于SqlSugar的开发框架循序渐进介绍(7)-- 在文件上传模块中采用选项模式【Options】处理常规上传和FTP文件上传


基于SqlSugar的开发框架循序渐进介绍(8)-- 在基类函数封装实现用户操作日志记录


基于SqlSugar的开发框架循序渐进介绍(9)-- 结合Winform控件实现字段的权限控制


基于SqlSugar的开发框架循序渐进介绍(10)-- 利用axios组件的封装,实现对后端API数据的访问和基类的统一封装处理


基于SqlSugar的开发框架循序渐进介绍(11)-- 使用TypeScript和Vue3的Setup语法糖编写页面和组件的总结


基于SqlSugar的开发框架循序渐进介绍(12)-- 拆分页面模块内容为组件,实现分而治之的处理


基于SqlSugar的开发框架循序渐进介绍(13)-- 基于ElementPlus的上传组件进行封装,便于项目使用


基于SqlSugar的开发框架循序渐进介绍(14)-- 基于Vue3+TypeScript的全局对象的注入和使用


基于SqlSugar的开发框架循序渐进介绍(15)-- 整合代码生成工具进行前端界面的生成


基于SqlSugar的开发框架循序渐进介绍(16)-- 工作流模块的功能介绍


基于SqlSugar的开发框架循序渐进介绍(17)-- 基于CSRedis实现缓存的处理


基于SqlSugar的开发框架循序渐进介绍(18)-- 基于代码生成工具Database2Sharp,快速生成Vue3+TypeScript的前端界面和Winform端界面


基于SqlSugar的开发框架循序渐进介绍(19)-- 基于UniApp+Vue的移动前端的功能介绍


基于SqlSugar的开发框架循序渐进介绍(20)-- 在基于UniApp+Vue的移动端实现多条件查询的处理


基于SqlSugar的开发框架循序渐进介绍(21)-- 在工作流列表页面中增加一些转义信息的输出,在后端进行内容转换


基于SqlSugar的开发框架循序渐进介绍(22)-- Vue3+TypeScript的前端工作流模块中实现统一的表单编辑和表单详情查看处理

我们如果要在服务器上发布https前端应用和WebAPI的应用,那么我们就需要用到https证书了。我们一般发布的应用的云服务器上,都会提供一定量的相关的免费证书(一般为20个)供我们使用,每个一年期限,到期再续即可,一般情况下基本上满足要求了,本篇随笔介绍如何基于云服务提供商的免费证书,在服务器上发布Nginx的前端应用和基于IIS的Web API接口的https应用处理。

1、申请免费证书

如阿里云和腾讯云,他们云服务器管理控制台上,都可以找到对应免费https的SSL证书申请的入口,如下所示。

在申请界面上,填入所需的域名,以及相关信息就可以发起申请了,申请后等待一点时间就会成功了,如阿里云的申请界面如下。

而腾讯云上的申请入口也是类似,如下界面所示。

申请成功后,在列表中就可以看到下载SSL证书的信息了。如下所示。

在下载界面上,我们可以看到不同部署服务器上的不同证书下载入口,选择我们具体的(如这里用到了Nginx和IIS的SSL证书文件)

我们选择所需的证书文件下载下来备用即可。下面会继续介绍IIS证书的安装和使用,以及Nginx的证书文件处理实现https的应用和接口服务。

2、发布基于IIS的Web API的https应用接口

如我们先下载IIS的证书文件,我们可以看到除了证书文件,还有一个附带的文本文件,是证书的密码信息。

我们双击进行证书的安装,选择本地计算机的存储位置即可。

然后输入所需的证书密码,完成安装就可以了。

发布一个IIS的Web API应用,然后在右键进行端口的绑定处理,设置绑定的为https,指定端口,并指定具体的SSL证书就是了,如下所示。

绑定的界面如下所示。

这样IIS的服务器端的Web API就可以使用https的协议了。

3、发布Nginx的前端应用

我们的前端是基于Vue的应用的,因此应用发布后,使用Nginx发布前端应用更为方便,因此这里介绍使用SSL免费证书在服务器上发布Nginx的前端应用,以便使用https协议访问。

前面我们提到了在申请完免费的SSL证书后,下载对应的Nginx的SSL证书文件。

基于Nginx的SSL证书设置,有两种方式,一种是创建一个ssl.conf文件,设置ssl.conf的方式指定对应的证书信息,如下所示。

#ssl.conf文件内容

server {
listen
8080 ssl http2;server_name localhost;ssl_certificate C:/WebRoot/nginx/conf/ssl/www.iqidi.com_bundle.crt;ssl_certificate_key C:/WebRoot/nginx/conf/ssl/www.iqidi.com.key; #先配置签名证书,再配置加密证书,签名加密证书私钥 key 为同一个!
ssl_session_timeout 5m
;ssl_protocols TLSv1.2;ssl_ciphers SM2-WITH-SMS4-SM3:ECDH:AESGCM:HIGH:MEDIUM:!RC4:!DH:!MD5:!aNULL:!eNULL;ssl_prefer_server_cipherson;location/{
root html
/CollectDataApp;index index.html index.htm;}
}

这样我们在conf/nginx.conf 文件中设置端口侦听,就可以了

server {
listen
8080 ssl;server_name localhost; #charset koi8-r; #access_log logs/host.access.log main;location/{
root html
/CollectDataApp;index index.html index.htm;try_files$uri $uri/ /index.html =404;}}

如果是不想独立分开两个配置文件,也可以把SSL证书位置信息写在conf/nginx.conf 文件中,也是可以的,如下所示。

server {
listen
9002 ssl;server_name localhost;ssl_certificate C:/WebRoot/nginx/conf/ssl/www.iqidi.com_bundle.crt;
ssl_certificate_key C:/WebRoot/nginx/conf/ssl/www.iqidi.com.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
#charset koi8-r; #access_log logs/host.access.log main;location/{
root html
/AssetCheckApp;index index.html index.htm;try_files$uri $uri/ /index.html =404;}}

这样就合并了SSL设置和端口侦听的文件在一起,测试后正常使用了。

以上就是关于利用云服务提供商的免费证书,在服务器上发布https前端应用和WebAPI的应用的整个过程,证书解决了,根据不同的应用服务器,设置好对应的方式就可以实现https应用了。

一旦我们完成了免费证书的申请、下载,那么在服务器上不同端口的应用,都可以使用这个证书作为SSL证书,从而实现多个不同应用端口上公用一个SSL证书了,因为证书对应的是一个相同域名的,因此可以正常使用。

在前面随笔介绍的基于SqlSugar的WInform端管理系统中,数据提供者是直接访问数据库的方式,不过窗体界面调用数据接口获取数据的时候,我们传递的是标准的接口,因此可扩展性比较好。我曾经在随笔《
基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接口注入方式实现IOC控制反转
》中介绍过,该SqlSugar开发框架本身是基于IOC控制反转的,因此对于接入不同的数据提供者,只需要切换到对应的实现层上即可。本篇随笔介绍基于SqlSugar开发框架的Winform端,实现包括对直接访问数据库,远程调用Web API接口的两种不同的处理方式的整合。

1、Winform模块中对具体接口的调用及接口注册

Winform中的界面展示,以及数据处理,都需要具体实现的支撑,由于本身IOC控制反转的接口设计,我们对具体数据的访问,也是基于特定的接口层进行调用的,具体的实现,则是在程序启动的时候,注入对应的接口实现即可。

例如对于客户信息的展示业务操作,代码如下所示

/// <summary>
///数据显示的函数/// </summary>
public async override voidDisplayData()
{
if (!string.IsNullOrEmpty(ID))
{
#region 显示信息 var info = await BLLFactory<ICustomerService>.Instance.GetAsync(ID);if (info != null)
{
tempInfo
= info;//重新给临时对象赋值,使之指向存在的记录对象txtName.Text=info.Name;
txtAge.Value
=info.Age;
}
#endregion //this.btnOK.Enabled = HasFunction("Customer/Edit"); }else{//this.btnOK.Enabled = HasFunction("Customer/Add"); }
}

上面代码可以看到,我们是调用接口进行数据的处理的,而这个接口就是在程序启动之处,通过自动的方式获得对应的接口和实现类,然后进行注入的。

.net 中 负责依赖注入和控制反转的核心组件有两个:IServiceCollection和IServiceProvider。其中,IServiceCollection负责注册,IServiceProvider负责提供实例。

在注册接口和类时,
IServiceCollection
提供了三种注册方法,如下所示:

1、services.AddTransient<IDictDataService, DictDataService>();  // 瞬时生命周期
2、services.AddScoped<IDictDataService, DictDataService>();     // 域生命周期
3、services.AddSingleton<IDictDataService, DictDataService>();  // 全局单例生命周期

如果使用
AddTransient
方法注册,
IServiceProvider
每次都会通过
GetService
方法创建一个新的实例;

如果使用
AddScoped
方法注册, 在同一个域(
Scope
)内,
IServiceProvider
每次都会通过
GetService
方法调用同一个实例,可以理解为在局部实现了单例模式;

如果使用
AddSingleton
方法注册, 在整个应用程序生命周期内,
IServiceProvider
只会创建一个实例。

前面说到,接口我们是自动遍历响应的程序集进行注册的,注册接口的逻辑,我们可以统一抽取唯一个公用的函数处理,如下代码所示。

        /// <summary>
        ///配置依赖注入对象/// </summary>
        /// <param name="services"></param>
        public static voidConfigureRepository(IServiceCollection services)
{
#region 自动注入对应的服务接口 var path = AppDomain.CurrentDomain.RelativeSearchPath ??AppDomain.CurrentDomain.BaseDirectory;var getFiles = Directory.GetFiles(path, "*.dll").Where(Match); //.Where(o=>o.Match()) var referencedAssemblies = getFiles.Select(Assembly.LoadFrom).ToList(); //.Select(o=> Assembly.LoadFrom(o)) var baseType = typeof(IDependency);var types =referencedAssemblies
.SelectMany(a
=>a.DefinedTypes)
.Select(type
=>type.AsType())
.Where(x
=> x != baseType &&baseType.IsAssignableFrom(x)).ToList();var implementTypes = types.Where(x =>x.IsClass).ToList();var interfaceTypes = types.Where(x =>x.IsInterface).ToList();

RegisterService(services, implementTypes, interfaceTypes);
#endregion}

如果我们这里增加一个对Web API的调用,那么在这里注册的时候,切换向Web API代理的注册接口就可以,如下图所示。

因此原来的Winform界面上的调用代码,不需要任何变化,只需要注入不同的接口实现,就能获得不同的方式:普通访问数据库方式,还是分布式获取服务WebAPI的处理方式。

通过切换开关变量的方式,客户可以非常方便的自由切换不同的数据访问方式。数据提供服务,可以是直接访问数据库的方式,也可以是远端的Web API服务方式,从而实现更加广泛的业务需求。

根据不同开关变量,处理不同的接口注册的代码如下所示。

/// <summary>
///根据配置文件,决定采用直连的DLL,还是代理API的DLL,构建接口进行注入/// </summary>
/// <param name="services"></param>
public static voidConfigureRepositoryAuto(IServiceCollection services)
{
var config = newAppConfig();string callerType = config.AppConfigGet("CallerType");if (!string.IsNullOrWhiteSpace(callerType) && callerType.Equals("api", StringComparison.OrdinalIgnoreCase))
{
//如果配置为API模式 ConfigureRepositoryApi(services);
}
else{//如果配置为普通模式 ConfigureRepository(services);
}
}

API方式的注册,和普通的注册方式类似,就是定位具体的实现,获得接口和具体的实现对象,进行服务注册即可,在此不再赘述。

2、具体的Web API代理实现

在随笔《
基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接口注入方式实现IOC控制反转
》我们介绍过具体实现类的继承关系,一般都是构建相应的基类和接口,然后才是具体的业务实现和接口,这样处理可以重用基类的很多接口,提高代码的重用效率。

我们以其中简单的Customer业务表为例,它的服务类代码如下所示(主要关注服务类的定义即可)。

    /// <summary>
    ///客户信息应用层服务接口实现/// </summary>
    public class CustomerService : MyCrudService<CustomerInfo, string, CustomerPagedDto>, ICustomerService
{
...............
}

而对应Web API的代理调用类,那么为了极大的重用常规的接口处理,我们需要类似的继承关系。

具体的代码实现关系如下所示。

/// <summary>
///客户信息的Web API调用处理/// </summary>
public class CustomerApiCaller : AsyncCrudApiCaller<CustomerInfo, string, CustomerPagedDto>, ICustomerService
{
}

我们可以利用代码生成工具生成主要的继承关系,然后实现具体的函数封装即可。我们独立一个项目用来承载API的代理类处理。

在AsyncCrudApiCaller 类中做了很多Web API的调用封装,对于接口的访问,是需要令牌的,因此在用户访问其他接口前,需要获取用户身份令牌信息,并缓存起来供后续使用。

/// <summary>
///对用户身份进行认证/// </summary>
/// <param name="username">用户名</param>
/// <param name="password">用户密码</param>
/// <returns></returns>
public async virtual Task<AuthenticateResultDto> Authenticate(string username, stringpassword)
{
var url = string.Format("{0}/api/Login/Authenticate", ServerRootAddress);var input = new{
UsernameOrEmailAddress
=username,
Password
=password
};
var result = await apiClient.PostAsync<AuthenticateResultDto>(url, input);returnresult;
}

后续每次接口访问的时候,填入相应的令牌信息。

/// <summary>
///重新增加相应的请求头,如认证的信息/// </summary>
protected virtual voidAddRequestHeaders()
{
//读取需要设置的请求头 apiClient.RequestHeaders.Clear();foreach (var item inRequestHeaders)
{
apiClient.RequestHeaders.Add(item);
}
//从缓存里面读取令牌信息,并在请求的时候自动加入(如果没有加的话) var accessToken = Cache.Instance["AccessToken"] as string;if (!string.IsNullOrWhiteSpace(accessToken))
{
var bearer = new NameValue("Authorization", "Bearer " +accessToken);if (apiClient.RequestHeaders != null && !apiClient.RequestHeaders.Contains(bearer))
{
apiClient.RequestHeaders.Add(bearer);
}
}
}

而ApiCaller的实现类此对于具体的调用,由于封装了相应的处理类,因此操作代码是比较简单的。

/// <summary>
///获取所有对象列表/// </summary>
/// <returns></returns>
public async virtual Task<ListResultDto<TEntity>>GetAllAsync()
{
return await DoActionAsync<PagedResultDto<TEntity>>("all");
}
/// <summary> ///获取所有对象列表/// </summary> /// <param name="input">获取所有条件</param> /// <returns></returns> public async virtual Task<ListResultDto<TEntity>> GetAllByIdsAsync(IEnumerable<TPrimaryKey>input)
{
return await DoActionAsync<PagedResultDto<TEntity>>("all-byids", input);
}

GET参数可以选用Dict方式传递,或者直接传入匿名类也可以,后台代码自动生成相关的URL参数传递的。

public async Task<bool> SetDeletedFlag(int id, bool deleted = true)
{
var action = $"set-deleted";var input = new{
id,
deleted
};
return await DoActionAsync<bool>(action, input, HttpVerb.Post);
}
public async Task<OuInfo> FindByName(stringname)
{
var action = $"byname/{name}";var dict = new Dictionary<string, string> { { "name", name } };return await DoActionAsync<OuInfo>(action, dict, HttpVerb.Get);
}

剩下的任务就是完善ApiCaller项目的类,与Web API控制器提供的接口的对应关系了,处理完成后,就可以进行测试了。

只要做好模块接口的对接关系,界面的处理代码不用变化就可以切换到其他方式上去了(如Web API的数据提供方式)。

系列文章:


基于SqlSugar的开发框架的循序渐进介绍(1)--框架基础类的设计和使用


基于SqlSugar的开发框架循序渐进介绍(2)-- 基于中间表的查询处理


基于SqlSugar的开发框架循序渐进介绍(3)-- 实现代码生成工具Database2Sharp的整合开发


基于SqlSugar的开发框架循序渐进介绍(4)-- 在数据访问基类中对GUID主键进行自动赋值处理


基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接口注入方式实现IOC控制反转


基于SqlSugar的开发框架循序渐进介绍(6)-- 在基类接口中注入用户身份信息接口


基于SqlSugar的开发框架循序渐进介绍(7)-- 在文件上传模块中采用选项模式【Options】处理常规上传和FTP文件上传


基于SqlSugar的开发框架循序渐进介绍(8)-- 在基类函数封装实现用户操作日志记录


基于SqlSugar的开发框架循序渐进介绍(9)-- 结合Winform控件实现字段的权限控制


基于SqlSugar的开发框架循序渐进介绍(10)-- 利用axios组件的封装,实现对后端API数据的访问和基类的统一封装处理


基于SqlSugar的开发框架循序渐进介绍(11)-- 使用TypeScript和Vue3的Setup语法糖编写页面和组件的总结


基于SqlSugar的开发框架循序渐进介绍(12)-- 拆分页面模块内容为组件,实现分而治之的处理


基于SqlSugar的开发框架循序渐进介绍(13)-- 基于ElementPlus的上传组件进行封装,便于项目使用


基于SqlSugar的开发框架循序渐进介绍(14)-- 基于Vue3+TypeScript的全局对象的注入和使用


基于SqlSugar的开发框架循序渐进介绍(15)-- 整合代码生成工具进行前端界面的生成


基于SqlSugar的开发框架循序渐进介绍(16)-- 工作流模块的功能介绍


基于SqlSugar的开发框架循序渐进介绍(17)-- 基于CSRedis实现缓存的处理


基于SqlSugar的开发框架循序渐进介绍(18)-- 基于代码生成工具Database2Sharp,快速生成Vue3+TypeScript的前端界面和Winform端界面


基于SqlSugar的开发框架循序渐进介绍(19)-- 基于UniApp+Vue的移动前端的功能介绍


基于SqlSugar的开发框架循序渐进介绍(20)-- 在基于UniApp+Vue的移动端实现多条件查询的处理


基于SqlSugar的开发框架循序渐进介绍(21)-- 在工作流列表页面中增加一些转义信息的输出,在后端进行内容转换


基于SqlSugar的开发框架循序渐进介绍(22)-- Vue3+TypeScript的前端工作流模块中实现统一的表单编辑和表单详情查看处理


基于SqlSugar的开发框架循序渐进介绍(23)-- Winform端管理系统中平滑增加对Web API对接的需求


基于SqlSugar的开发框架循序渐进介绍(24)-- 使用Serialize.Linq对Lambda表达式进行序列化和反序列化