分类 其它 下的文章

在ABP开发框架中应用服务层ApplicationService类中,都会提供常见的一些如GetAll、Get、Create、Update、Delete等的标准处理接口,而由于在ApplicationService类定义的时候,都会传入几个不同的类型作为泛型的参数,实现强类型的类型处理,本篇随笔对于分页查询排序的实现处理做一个详细的介绍,介绍其中对分页查询条件的定义,子类应用服务层的条件查询逻辑重写、排序逻辑重写等规则的处理。

1、ApplicationService类的泛型定义

例如我们定义User应用服务层的UserApplicationService的时候,传入了几个不同类型的参数作为基类的泛型约束类型,如下所示。

[AbpAuthorize]public class UserAppService: MyAsyncServiceBase<User, UserDto, long, UserPagedDto, CreateUserDto, UserDto>, IUserAppService

同类型的字典数据应用服务层的定义如下所示,可以看到和UserAppService类似的。

其中MyAsyncServiceBase则是我们自定义的一个基类对象,主要是根据传入不同的参数构造不同的强类型对象返回。

    public abstract class MyAsyncServiceBase<TEntity, TEntityDto, TPrimaryKey, TGetAllInput, TCreateInput, TUpdateInput, TGetInput, TDeleteInput>: 
AsyncCrudAppService
<TEntity, TEntityDto, TPrimaryKey, TGetAllInput, TCreateInput, TUpdateInput, TGetInput, TDeleteInput> where TEntity : class, IEntity<TPrimaryKey> where TEntityDto : IEntityDto<TPrimaryKey> where TUpdateInput : IEntityDto<TPrimaryKey> where TGetInput : IEntityDto<TPrimaryKey> where TDeleteInput : IEntityDto<TPrimaryKey>

这里UserApplicationService的服务层中参数的User类,对应是EFCore的领域对象,它的定义如下所示

    public class User : AbpUser<User>

由于User需要集成AbpUser基类的一些特性,因此有继承关系,它主要就是负责和数据库模型打交道的对象。

而如果不是类似User这样系统用到的基类对象,那么我们就需要如下定义,指定表单的名称,以及对象的约束条件了,如下字典的领域对象如下定义所示。

而 MyAsyncServiceBase 的第二个参数则是用于传递的DTO对象,可以认为它和数据库没有直接的关系,不过由于引入了AutoMapper,我们一般看它们的属性还是有很多相同的地方,不过DTO更加面向的是业务界面,而非存储处理。

如果对于一些界面特殊的数据信息,需要转换为领域对象的属性,则需要进行特别的自定义映射处理了。

如User的DTO对象定义如下所示。

而如果我们的DTO对象,不需要利用ABP进行参数内容的约束,那么可以更加简化一些条件,如下字典DTO对象所示。

对于类似下面的字典模块的应用服务层定义

其中第三个参数是主键ID的类型,如果为Int这是整形,这里是字符串类型,因此使用string。

第四个参数DictDataPagedDto就是分页查询的条件 ,这个DTO对象,主要就是获取客户端查询处理的条件的,因此可以根据需要查询的条件进行裁剪,默认利用代码生成工具Database2sharp生成的属性基本上包括了所有的数据库表属性名称了。如字典数据的查询条件比较简单,如下所示,除了包含一些分页条件信息外,就是包含所需要的查询条件属性了。

    /// <summary>
    ///用于根据条件分页查询/// </summary>
    public classDictDataPagedDto : PagedAndSortedInputDto
{
public DictDataPagedDto() : base() { }/// <summary> ///参数化构造函数/// </summary> /// <param name="skipCount">跳过的数量</param> /// <param name="resultCount">最大结果集数量</param> public DictDataPagedDto(int skipCount, int resultCount) : base(skipCount, resultCount)
{
}
/// <summary> ///使用分页信息进行初始化SkipCount 和 MaxResultCount/// </summary> /// <param name="pagerInfo">分页信息</param> public DictDataPagedDto(PagerInfo pagerInfo) : base(pagerInfo)
{
}
/// <summary> ///字典类型ID/// </summary> public virtual string DictType_ID { get; set; }/// <summary> ///类型名称/// </summary> public virtual string Name { get; set; }/// <summary> ///指定值/// </summary> public virtual string Value { get; set; }/// <summary> ///备注/// </summary> public virtual string Remark { get; set; }
}

2、分页查询排序的实现处理

前面我们介绍了应用服务层中利用泛型基类的参数定义,可以强类型返回各项不同数据接口,这种就是非常弹性化的设计模式了。

ABP+Swagger负责API接口的开发和公布,如下是API接口的管理界面。

进一步查看GetAll的API接口说明,我们可以看到对应的条件参数,如下所示。

这些是作为查询条件的处理,用来给后端获取对应的条件信息,从而过滤返回的数据记录的。

那么我们前端界面也需要根据这些参数来构造查询界面,我们可以通过部分条件进行处理即可,其中MaxResultCount和SkipCount是用于分页定位的参数。

我们来看看基类对于查询分页排序的处理函数,从而了解它的处理规则。

        public virtual async Task<PagedResultDto<TEntityDto>>GetAllAsync(TGetAllInput input)
{
//判断权限 CheckGetAllPermission();//获取分页查询的条件 var query =CreateFilteredQuery(input);//根据条件获取所有记录数 var totalCount = awaitAsyncQueryableExecuter.CountAsync(query);//对查询内容排序和分页 query =ApplySorting(query, input);
query
=ApplyPaging(query, input);//返回领域实体对象 var entities = awaitAsyncQueryableExecuter.ToListAsync(query);//构造返回结果集,并转换实体类为DTO对应 return new PagedResultDto<TEntityDto>(
totalCount,
entities.Select(MapToEntityDto).ToList()
);
}

其中 CreateFilteredQuery 、ApplySorting和 ApplyPaging 都是利用可以子类重写的函数实现弹性化的逻辑调整处理。

在基类中,默认的CreateFilteredQuery 提供了简单的返回所有列表的处理,并不处理查询条件,这个具体的条件过滤由子类实现逻辑的。

protected virtual IQueryable<TEntity>CreateFilteredQuery(TGetAllInput input)
{
returnRepository.GetAll();
}

而列表排序处理ApplySorting的基类函数,基类提供了标准的对Sorting 属性进行条件排序,否则就根据主键ID进行倒序排序处理,如下代码所示。

protected virtual IQueryable<TEntity> ApplySorting(IQueryable<TEntity>query, TGetAllInput input)
{
//Try to sort query if available var sortInput = input asISortedResultRequest;if (sortInput != null)
{
if (!sortInput.Sorting.IsNullOrWhiteSpace())
{
returnquery.OrderBy(sortInput.Sorting);
}
}
//IQueryable.Task requires sorting, so we should sort if Take will be used. if (input isILimitedResultRequest)
{
return query.OrderByDescending(e =>e.Id);
}
//No sorting returnquery;
}

而基类的分页的处理ApplyPaging逻辑,主要就是转换为标准的接口进行处理,如下代码所示。

protected virtual IQueryable<TEntity> ApplyPaging(IQueryable<TEntity>query, TGetAllInput input)
{
//Try to use paging if available var pagedInput = input asIPagedResultRequest;if (pagedInput != null)
{
returnquery.PageBy(pagedInput);
}
//Try to limit query result if available var limitedInput = input asILimitedResultRequest;if (limitedInput != null)
{
returnquery.Take(limitedInput.MaxResultCount);
}
//No paging returnquery;
}

以上是标准基类提供的几个可以重写的默认实现,一般来说,我们会通过子类重写逻辑实现的方式进行逻辑重写的。

如对于字典模块的条件信息,我们可以进行重写,以便实现自定义的条件查询处理,如下DictDataAppService应用服务层的重写处理。

/// <summary>
///自定义条件处理/// </summary>
/// <param name="input"></param>
/// <returns></returns>
protected override IQueryable<DictData>CreateFilteredQuery(DictDataPagedDto input)
{
return base.CreateFilteredQuery(input)
.WhereIf(
!input.Name.IsNullOrWhiteSpace(), t =>t.Name.Contains(input.Name))
.WhereIf(
!string.IsNullOrEmpty(input.Remark), t =>t.Remark.Contains(input.Remark))
.WhereIf(
!string.IsNullOrEmpty(input.Value), t => t.Value ==input.Value)
.WhereIf(
!string.IsNullOrEmpty(input.DictType_ID), t => t.DictType_ID ==input.DictType_ID);
}

而对于属性比较复杂的查询,我们适当调整这个函数的处理基类,一般都可以根据代码生成工具进行生成的,特殊条件自己微调一下就没问题了。

如用户应用服务层类UserAppService的重写自定义条件的函数,代码如下所示。

/// <summary>
///自定义条件处理/// </summary>
/// <param name="input">查询条件Dto</param>
/// <returns></returns>
protected override IQueryable<User>CreateFilteredQuery(UserPagedDto input)
{
return Repository.GetAllIncluding(x => x.Roles) //base.CreateFilteredQuery(input) .WhereIf(input.ExcludeId.HasValue, t => t.Id != input.ExcludeId) //不包含排除ID .WhereIf(!input.EmailAddress.IsNullOrWhiteSpace(), t => t.EmailAddress.Contains(input.EmailAddress)) //如需要精确匹配则用Equals .WhereIf(input.IsActive.HasValue, t => t.IsActive == input.IsActive) //如需要精确匹配则用Equals .WhereIf(input.IsEmailConfirmed.HasValue, t => t.IsEmailConfirmed == input.IsEmailConfirmed) //如需要精确匹配则用Equals .WhereIf(input.IsPhoneNumberConfirmed.HasValue, t => t.IsPhoneNumberConfirmed == input.IsPhoneNumberConfirmed) //如需要精确匹配则用Equals .WhereIf(!input.Name.IsNullOrWhiteSpace(), t => t.Name.Contains(input.Name)) //如需要精确匹配则用Equals .WhereIf(!input.PhoneNumber.IsNullOrWhiteSpace(), t => t.PhoneNumber.Contains(input.PhoneNumber)) //如需要精确匹配则用Equals .WhereIf(!input.Surname.IsNullOrWhiteSpace(), t => t.Surname.Contains(input.Surname)) //如需要精确匹配则用Equals .WhereIf(!input.UserName.IsNullOrWhiteSpace(), t => t.UserName.Contains(input.UserName)) //如需要精确匹配则用Equals .WhereIf(!input.UserNameOrEmailAddress.IsNullOrWhiteSpace(), t =>t.UserName.Contains(input.UserNameOrEmailAddress)|| t.EmailAddress.Contains(input.UserNameOrEmailAddress) ||t.FullName.Contains(input.UserNameOrEmailAddress))//创建日期区间查询 .WhereIf(input.CreationTimeStart.HasValue, s => s.CreationTime >=input.CreationTimeStart.Value)
.WhereIf(input.CreationTimeEnd.HasValue, s
=> s.CreationTime <=input.CreationTimeEnd.Value);
}

可以看出会根据UserPageDto的属性不同,从而增加更多的处理条件,有的是完全匹配,有些这是模糊匹配,有些如日期则是范围匹配。

对于数值、日期等有区间范围的属性,我们条件的DTO对象中,往往都有一个Start和End的起始值参数的。

这样我们在利用Vue&Element的前端进行查询的时候,可以构造对应的区间参数了,如下前端代码所示。

有时候,为了简化前端的日期区间代码,我们可以通过辅助类来简化处理。

而自定义排序的处理,则可以根据实际的需要进行排序处理,对于自增长的ID类型,使用ID倒序显示倒是问题不大,而如果是字符串类型,本身是GUID的类型,那么使用ID类排序这是没有任何意义的,因此必须通过重写基类函数的方式实现逻辑重写。

/// <summary>
///自定义排序处理/// </summary>
/// <param name="query"></param>
/// <param name="input"></param>
/// <returns></returns>
protected override IQueryable<DictData> ApplySorting(IQueryable<DictData>query, DictDataPagedDto input)
{
//先按字典类型排序,然后同一个字典类型下的再按Seq排序 return base.ApplySorting(query, input).OrderBy(s=>s.DictType_ID).ThenBy(s =>s.Seq);
}

具体情况根据ID的特点或者排序的具体情况进行排序即可。

最后一项是分页的处理,则可以按标准的方式处理,默认可以不重写。

这样我们前面提到的几个函数的逻辑,我们根据实际情况重写部分逻辑即可,从而非常弹性化的实现了条件的处理,排序的处理,分页的处理等规则。

public virtual async Task<PagedResultDto<TEntityDto>>GetAllAsync(TGetAllInput input)
{
//判断权限 CheckGetAllPermission();//获取分页查询的条件 var query =CreateFilteredQuery(input);//根据条件获取所有记录数 var totalCount = awaitAsyncQueryableExecuter.CountAsync(query);//对查询内容排序和分页 query =ApplySorting(query, input);
query
=ApplyPaging(query, input);//返回领域实体对象 var entities = awaitAsyncQueryableExecuter.ToListAsync(query);//构造返回结果集,并转换实体类为DTO对应 return new PagedResultDto<TEntityDto>(
totalCount,
entities.Select(MapToEntityDto).ToList()
);
}

因此,不管是Winform端,或者Vue&Element的BS前端,都可以通过不同的条件信息进行快速的查询排序处理了。

菜单资源管理的列表界面界面如下所示

用户列表包括分页查询及列表展示、以及可以利用按钮进行新增、编辑、查看用户记录,或者对指定用户进行重置密码操作。

在我们开发各种项目应用的时候,往往都是基于一定框架进行,同时配合专用的代码生成工具,都是为了快速按照固定模式开发项目,事半功倍,本篇随笔对基于ABP开发框架的技术点进行分析和ABP框架项目快速开发实现进行介绍,抛砖引玉的对我们技术人员的日常技术工作进行一定的总结,希望大家不吝支持。

1、ABP开发框架的项目开发

下面对ABP框架的数据库支持、管理端界面、功能模块划分、ABP框架特点、模块开发支持等方面进行介绍,如下图所示。

我们知道,一般我们开发某个项目的时候,往往都会关注项目默认支持的数据库,以及后续能够支持的一些数据库,对于一般的应用,当然是希望它能够支持多种数据库。

对于ABP框架来说,它的底层是基于.netcore的Entity Framework Core ,它对于常规的数据库基本上都是支持的,如下所示。

关于ABP框架使用Oracle数据库及数据库的迁移,可以参考我的随笔《
ABP框架使用Oracle数据库,并实现从SQLServer中进行数据迁移的处理

关于ABP框架使用Mysql数据库及数据库的迁移,可以参考我的随笔《
ABP框架使用Mysql数据库,以及基于SQLServer创建Mysql数据库的架构和数据

现在框架基本上都是多端应用的了,所以在ABP框架中整合Winform管理端、Vue&element的BS前端,以及公司动态网站用于发布产品和网站信息等都是常见的应用,有时候,我们还需要根据功能的需要,增加一些小程序的支持,这些对于Web API后端来说,都是很容易接入的应用处理。

Winform应用端,其实很多时候是很必要的,提供众多丰富的功能展示,以及很好的用户交互能力,特别在对接硬件或者打印处理的时候。

和我们的Winform框架一样,Winform应用端提供封装良好的框架组件模块,包括权限系统、字典模块、附件管理模块、自动升级、分页控件、公用类库及界面基类模块等模块。

而基于Vue + Element 的前端界面,和基于Winform的ABP框架一样,使用同一个API后端,模块包括用户管理、组织机构管理、角色管理、菜单管理、功能管理及权限分配,日志管理、字典管理、产品管理等管理功能,可实现用户的功能及数据权限进行控制管理。

公司动态门户网站,有时候用于我们发布网站信息和产品信息的一个门户网站,采用了Bootstrap-Vue界面组件,由于大多数门户网站都是基于Bootstrap栅格系统的,因此基于最新Bootstrap-Vue界面组件也就是最佳选择的了,而且可以重用很多Bootstrap的网站模板案例。这样也同时保持了前端模块同时也是基于Vue的,摒弃了以前基于JQuery的繁琐操作DOM处理。

有了这些管理端,基本上也就满足了大部分的需求,不过由于现在微信小程序的广泛应用,有时候我们针对一些业务模块功能,可以根据需要推出一些小程序应用场景,这些对接我们的统一授权系统,以及统一的WebAPI调用机制即可满足。

前面介绍了,基于ABP开发框架的Winform端、Vue&Element前端,都整合了很多常规的模块,如权限、字典、附件等常见的模块,这些既可以是系统性的管理模块,也是基础性数据的支撑,同时也会提供众多组件给我们应用模块进行使用的。

而我们在框架提供这些内容外,都需要根据具体业务的需要,按照框架的架构、编码标准要求,增量式的开发一些业务模块界面,一般最好的清空下是借助辅助工具的使用,能够节省大量的时间,同时降低难度,事半功倍。

2、ABP框架的代码生成

借助我们ABP框架的定制代码生成工具Database2sharp,可以对Winform界面开发、Vue&Element界面开发、ABP框架后端代码进行全栈式的开发处理。

Database2sharp它通过整合框架相关的生成规则,我们可以增加对应的ABP框架后端代码的生成,如下代码生成工具界面所示。

Database2Sharp关于ABP框架的Winform界面配置如下界面所示,可以定制化的生成Winform界面代码。

在代码生成工具Database2Sharp界面里面,选择【代码生成】【ABP的Vue+Element界面代码】,如下所示。

确认生成代码后,我们可以看到对应的API调用JS类和Vue视图文件,如下所示。

3、ABP框架的特点

ABP框架,主要可以概括为下面几点。

详细的话,ABP框架涉及到的内容,包括下面这些。

  • 依赖注入
    ,这个部分使用 Castle windsor (依赖注入容器)来实现依赖注入,这个也是我们经常使用IOC来处理的方式;
  • Repository仓储模式
    ,已实现了Entity Framework、NHibernate、MangoDB、内存数据库等,仓储模式可以快速实现对数据接口的调用;
  • 身份验证与授权管理
    ,可以使用声明特性的方式对用户是否登录,或者接口的权限进行验证,可以通过一个很细粒度的方式,对各个接口的调用权限进行设置;
  • 数据有效性验证
    ,ABP自动对接口的输入参数对象进行非空判断,并且可以根据属性的申请信息对属性的有效性进行校验;
  • 审计日志记录
    ,也就是记录我们对每个接口的调用记录,以及对记录的创建、修改、删除人员进行记录等处理;
  • Unit Of Work工作单元模式
    ,为应用层和仓储层的方法自动实现数据库事务,默认所有应用服务层的接口,都是以工作单元方式运行,即使它们调用了不同的存储对象处理,都是处于一个事务的逻辑里面;
  • 异常处理
    ,ABP框架提供了一整套比较完善的流程处理操作,可以很方便的对异常进行进行记录和传递;
  • 日志记录
    ,我么可以利用Log4Net进行常规的日志记录,方便我们跟踪程序处理信息和错误信息;
  • 多语言/本地化支持
    ,ABP框架对多语言的处理也是比较友好的,提供了对XML、JSON语言信息的配置处理;
  • Auto Mapping自动映射
    ,这个是ABP的很重要的对象隔离概念,通过使用AutoMaper来实现域对象和DTO对象的属性映射,可以隔离两者的逻辑关系,但是又能轻松实现属性信息的赋值;
  • 动态Web API层
    ,利用这个动态处理,可以把Application Service 直接发布为Web API层,而不需要在累赘的为每个业务对象手工创建一个Web API的控制器,非常方便;
  • 动态JavaScript的AJax代理处理
    ,可以自动创建Javascript 的代理层来更方便使用Web Api,这个在Web层使用。

一般来说,对于数据库的操作,用标准仓储模式处理就可以了,而且我们基于框架的基类封装,可以减少很多标准的处理代码,只需要简单继承一下关系即可。

其中基类MyAsyncServiceBase 已经封装了常见的数据库操作处理。

而这个MyAsyncServiceBase 构造函数包含了相关的DTO对象,方便用于整个对象接口的处理,如查询条件、返回对象DTO、领域对象、主键类型等等。

如果不需要其他业务对象的操作,那么就保留默认的仓储对象即可,如果需要使用其他业务对象处理,那么同时引入,并在构造函数中注入所需的仓储对象,如下面所示。

一般来说,这些集成关系,我们在利用代码生成工具生成代码的时候,都已经完全处理好的了,各层的关系也都一一生成。

它主要是分为下面几个项目分层。

Core领域核心层
,领域层就是业务层,是一个项目的核心,所有业务规则都应该在领域层实现。这个项目里面,除了定义所需的领域实体类外,其实可以定义我们自己的自定义的仓储对象(类似DAL/IDAL),以及定义自己的业务逻辑层(类似BLL/IBLL),以及基于AutoMapper映射规则等内容。

EntityFrameworkCore
实体框架核心层,这个项目不需要修改太多内容,只需要在DbContext里面加入对应领域对象的仓储对象即可。

Application.Common和
Application应用层

:应用层提供一些应用服务(Application Services)方法供展现层调用。一个应用服务方法接收一个DTO(数据传输对象)作为输入参数,使用这个输入参数执行特定的领域层操作,并根据需要可返回另一个DTO。

Web.Core Web核心层
,基于Web或者Web API的核心层,提供了对身份登陆验证的基础处理,没有其他内容。

Web.Core.Host Web API的宿主层
,也是动态发布Web API的核心内容,另外在Web API里面整合了Swagger,使得我们可以方便对Web API的接口进行调试。

Migrator数据迁移层
,这个是一个辅助创建的控制台程序项目,如果基于DB First,我们可以利用它来创建我们项目的初始化数据库。

在我们基于框架开发系统的时候,往往对一些应用场景的页面对进行了归纳总结,因此对大多数情况下的页面呈现逻辑都做了清晰的分析,因此在我们基于框架的基础上,增量式开发业务功能的时候,能够事半功倍。代码生成工具Database2Sharp承载着我们各种开发框架的快速开发逻辑,包括界面代码的生成、后端代码的生成等内容,本篇随笔介绍在这个基础上,增加Vue&Element 工作流页面的快速生成,以便减轻我们实际开发工作流页面的繁琐工作。

1、工作流查看、编辑页面的组件动态化

在我的随笔《
基于Vue的工作流项目模块中,使用动态组件的方式统一呈现不同表单数据的处理方式
》中曾经介绍过,由于我们动态挂载了工作流的查看页面、编辑页面,因此我们可以根据工作流表单的属性,来动态呈现所需要的页面内容,也就是组件动态化的处理方式。也就是类似我们下图所示

除了查看表单、编辑表单,还有一个对具体业务申请单的查询页面,因此一个工作流表单,包含了三个特定功能的页面,如下所示。

申请表单查看的实际效果界面如下所示。

创建具体的表单的时候,根据表单的编辑界面,录入不同的流程申请单的数据,以及附件、清单、流程用户等信息。

不同的表单,有不同的查询界面,可以提供更加进行的业务表单数据查询或者统计处理,如对于付款申请单,我们提供一个付款申请单的分页查询页面。

这些页面的内容,我们在项目框架中存放的位置如下所示。

2、结合代码生成工具快速生成页面代码

根据上面的规则,我们可以使用代码生成工具,根据数据库的信息,结合页面的呈现需要,把查看申请单、创建/编辑申请单、列表查询几个页面的内容,通过代码生成工具Database2Sharp来快速生成,只需要根据需要定义好页面模板即可。

这里的ABP的Vue &Element界面代码,即可以用来生成基于ABP后端的Vue&Element前端界面代码,也可以基于Bootstrap&VUE框架的Web API前端界面代码,我们在这里生成包含常规页面的api+views视图代码外,同时也生成工作流模块所需的三类页面代码,生成的代码只需要简单的在VSCode中进行增量式的合并即可使用,节省了非常多的前端代码编写或者裁剪工作。

我们看到生成的工作流模块内容,已经根据edit /view / list几个目录进行了区分,如下所示。

这样我们把生成的页面,复制到对应的项目框架目录中即可。

其中对于对于主从表单的处理,我们可以通过利用Vxe-table插件的方式直接录入数据的方式进行录入 。通过代码生成工具,也是根据关联表的信息,我们同时生成所需要的从表信息展示,供裁剪录入信息处理。

<el-form-itemlabel="明细清单">
  <div>
    <vxe-toolbar>
      <template#buttons>
        <vxe-buttonstatus="primary"content="新增"@click="insertEvent" />
        <vxe-buttonstatus="warning"content="删除"@click="removeSelectEvent" />
        <vxe-buttoncontent="提交"@click="saveEvent" />
      </template>
    </vxe-toolbar>
    <vxe-tableref="xTable"border show-overflow keep-source resizable show-overflow :data="list":edit-config="{trigger: 'click', mode: 'row', showStatus: true}">
      <vxe-columntype="checkbox"width="60" />
      <vxe-columntype="seq"width="60" />
      <vxe-columnfield="feeType"title="费用类型":edit-render="{name: '$select', options: feeTypeList}" />
      <vxe-columnfield="occurTime"title="发生时间":edit-render="{name: '$input', props: {type: 'date', placeholder: '请选择日期'}}":formatter="formatDate" />
      <vxe-columnfield="feeAmount"title="费用金额(元)":edit-render="{name: '$input', props: {type: 'float', digits: 2}}" />
      <vxe-columnfield="feeDescription"title="费用说明":edit-render="{name: 'input', attrs: {type: 'text'}}" />
    </vxe-table>
  </div>
</el-form-item>

最终展示的界面效果如下所示。

利用代码生成工具Database2Sharp,我们可以非常细致的定义我们所需要生成的代码逻辑,因此在项目开发中,可以快速生成界面代码以及后端C#的框架处理代码,这样增量式的开发,往往能够做到事半功倍,并且在生成的界面代码里面,我们提供了很多控件的展示例子,供修改调整,灵活度非常好,同时也是我们快速进阶前端和后端开发的试金石。

以及API的生成代码,部分注释供参考。

代码生成工具Database2Sharp为开发效率而生,同时也是开发的好帮手,我们信奉开发中,自己所想要的东西,往往就是大多数开发者所需要的,尽可能的信手拈来。

我在起前面的几篇随笔中,大概介绍了工作流的一些场景化处理,包括如何把具体业务表单组件化,并在查看和编辑界面中,动态加载组件内容,以及对于查看申请单的主页面,把审批、取消、发起会签、会签、批示分阅、阅办等处理过程的进行模块化,并在主页面中灵活引入集成,本篇随笔综合性的介绍Vue&Element开发框架中增加的工作流各个管理界面的内容,以供参考交流。

1、工作流模块化划分

为了更有效的维护和管理工作流的设置和申请单信息,我们把工作流的内容分为三个大部分:工作流维护、工作流业务、业务表单。

工作流维护,主要是工作流模板的管理,包括流程模板的管理、以及流程环节的管理

工作流业务,主要是根据系统模板,提供创建流程申请单的入口(业务受理列表),我的审批工作(当前用户),所有审批工作(管理员维护),我的草稿(当前用户)

业务表单,这是根据具体表单的信息,提供查询统计的处理,包括各类业务表单,如付款申请单、物品领用单等等。

这些工作流的业务菜单如下所示。

2、流程环节管理

我们要开始一项工作流的申请单,首先需要配置好这个申请单的一些基本信息,其中流程环节就是决定每个步骤执行那种处理类型(如审批、撤销)的,因此流程环节也算是最基本的步骤类型定义了,也就是决定针对这类型的步骤的统一处理界面。

里面预定义了一些如审批、归档、会签、阅办等系统性的步骤类型,还可以根据需要自定义处理类型,自定义处理类型后,我们创建对应的处理规则即可在查看详细申请的界面中进行调用处理。

3、流程模板管理

完成了流程步骤类型的定义,就可以开始流程模板的管理了,流程模板主要配置相关工作流的信息,如表单的分类,对应数据表,流程步骤定义和顺序等等。

流程步骤的界面管理如下所示,可以通过双击修改,拖动调整顺序的方式管理各个步骤的信息。

编辑界面中,实现对流程模板的一些信息进行维护,如下所示。

最终,我们根据以上界面完成了流程模板和流程实例,以及相关步骤的设置处理,如下图所示。

4、业务受理列表

我们完成了流程模板,对于启用的流程模板,我们提供给用户创建具体的流程实例申请单,也就是提供创建流程申请单的入口。

由于我们约定了模板的名称和具体申请单的关系,因此查看申请单和编辑申请单的时候,使用的是同一个路由地址页面,而根据传入参数的不同,动态展示组件信息,供查看或者编辑处理。

但我们创建具体的表单的时候,根据表单的编辑界面,录入不同的流程申请单的数据,以及附件、清单、流程用户等信息。

对于主从表单的处理,我们可以通过利用Vxe-table插件的方式直接录入数据的方式进行录入 。

5、我的审批工作

我的审批工作,主要是根据当前用户列出不同类型(我发起的、我的待办、我的已办)等不同状态的申请单,从而可以快速处理自己的工作流审批业务工作。

通过双击行记录或者单击查看按钮,可以打开详细的申请单信息进行处理。

查看申请单中,会根据申请单的状态,以及当前用户的身份等等,自动展示可以操作流程的按钮。

其中流程日志展示相关的流程日志和系统日志等信息,供参考了解。

系统日志信息,则详细记录每个步骤的创建和处理信息。如在用户完成当前步骤的时候,自动创建新的流程步骤信息的日志。

6、所有审批工作

为了方便管理员查看不同的业务表单,以便核对处理或者删除等操作,我们提供了一个管理界面,可以看到所有申请单的记录信息,同时记录提供删除操作,删除申请单的时候,会把该申请单的相关步骤信息,执行用户信息,对应表单记录等信息一并抹除。

7、我的草稿

为了便于在创建申请单的时候暂存草稿信息,我们提供了一个通用的草稿存储表,用于存储任何信息的申请单信息。

在申请单创建界面里面,在末尾都会提供一个【保存草稿】的按钮,如下所示。

草稿的管理界面如下所示。

单击编辑按钮,可以对该草稿进行编辑,以便恢复到之前的录入状态。

8、业务表单

业务表单则是提供对具体类型的申请单数据进行查看,如下菜单所示。

这样不同的表单,有不同的查询界面,可以提供更加进行的业务表单数据查询或者统计处理。

相信大家最近被 ChatGPT 刷屏了,其实在差不多一个月前就火过一次,不会那会好像只在程序员的圈子里面火起来了,并没有被大众认知到,不知道最近是因为什么又火起来了,而且这次搞的人尽皆知。

想着这么火的 AI 完全可以好好玩一玩呀,于是就尝试着将 ChatGPT 接入到了个人微信中,实现在微信中调戏 AI

先看几个聊天截图

还可以拉入到一个群,进行群聊,可以看到 ChatGPT 的训练数据相当还是比较旧的,有些问题回答的还是历史的答案。不过从上面的 case 可以看到,目前的这个效果比以往要好很多的,最起码可以联系上下文了,不得不说,这绝对是一个里程碑。

流程

想要在微信中接入 ChatGPT 我们需要如下几个步骤

  1. 成功注册一个 OpenAi 的账号,获取的到一个 API key
  2. 基于开源项目 wechatbot 运行一个微信机器人程序;
  3. 用微信扫码登录(建议用小号);

注册

OpenAi 由于某些原因,在国内是无法正常注册账号的,并且连网站都是无法正常访问的,详细的注册流程不在本文的讨论范围之内,感兴趣的可以在 docs.qq.com/doc/DUE5NcFZQV1F5SHli 查看注册细节。

这里给大家演示一下注册成功后,如何获取一个 API key,当我们注册成功并且登录以后,可以在链接 https://platform.openai.com/account/api-keys,在页面上点击 Create new Secret key 即可生成一个 API key,复制 API key存放起来,后续备用。

运行机器人程序

对于技术出身的朋友,程序的运行有几种方式,可以基于源码来运行,也可以基于 docker 来运行,阿粉这边为了简单,就直接通过 docker 来运行,在服务上面安装好 docker 后,直接运行如下命令即可。

docker run -itd --name wechatbot --restart=always \
 -e APIKEY=刚刚生成的 API key \
 -e AUTO_PASS=false \
 -e SESSION_TIMEOUT=60s \
 -e MODEL=text-davinci-003 \
 -e MAX_TOKENS=512 \
 -e TEMPREATURE=0.9 \
 -e REPLY_PREFIX=ChatGPT: \
 -e SESSION_CLEAR_TOKEN=下一个问题 \
 docker.mirrors.sjtug.sjtu.edu.cn/qingshui869413421/wechatbot:latest

正常了说启动了过后,通过 docker ps 命令我们可以看到有相应的 docker 进程如下。

接下来我们进入的容器中,去查询二维码,并扫码登录,依次执行下面两行代码,不出意外的话,可以看到一个二维码出来,用微信扫码登录一下即可(建议用小号)。

docker exec -it wechatbot bash
tail -f -n 50 /app/run.log

扫码登录过后,我们就可以愉快的玩耍了,不过需要注意的是,API 的调用对于每个账户是有额度限制的,目前每个账户限制的是 18 美元,所以大家用来自己玩玩,调戏调戏 AI 就好,wechatbot 的项目地址在这里 https://github.com/qingconglaixueit/wechatbot ,感兴趣的也可以去研究研究。

思考

ChatGPT 的出现打破了以往的人工智障,虽然现在也还有很多不足的地方,相信在后面的迭代和升级中可以有更好的表现。同时 AI 目前已经越来越成熟,相信以后会有更多的工作岗位和技能将会被取代。

对于我们来说,唯一不变的就是变化,所以我们要做好接受新事物的准备,同时也做好应对未来的准备,尽量让自己变成不可替代的。

不会搭建的小伙伴可以根据下面的提示添加阿粉微信,阿粉会将搭建好的机器人拉进专门的读者群,可以体验一下,坑位有限先到先得。