CRUD老生常谈，但是我搜索了一圈，发觉几乎是着重在后端，也就是API部分！
无外乎2个思路
1.归总的接口，比如一个接口，实现不同表的CRUD
2.基于各自的表，使用代码生成器实现CRUD
个人来说是推荐2，虽然代码多了，其实结构更加清晰，而且！而且！后端对安全尤为重要！！！
啥？你说前端就不安全了？？？
前端！那不叫安全，那叫用户体验，体验懂否？
后端！那才是安全关口！重要的门户！！！！
如果使用1的方式，你会发觉到后续代码越来越臃肿，各种判断，到最后就像上了重庆的立交桥转个不停！
上次我们说到小程序的页面表单的动态化，先看下本次的要点

既然是系统，那肯定也少不了后台管理端的了，这里我使用的是原生的HTML，如果你喜欢那个VUE，其实可以按照这个思想自己实现！

##！！！VUE是前端点歪了技能树的产物！！！##

WebApi新增

距离上次的一发布后，后端接口我做了如下的调整！在WebApi中

        /// <summary>/// 读取AddDto的数据模型/// </summary>/// <returns></returns>[HttpGet]public PasteBuilderHelper.VoloModelInfo ReadAddModel(){var _model = PasteBuilderHelper.ReadModelProperty<WebsiteNoticeAddDto>(new WebsiteNoticeAddDto());return _model;}/// <summary>/// 读取UpdateDto的数据模型/// </summary>/// <returns></returns>[HttpGet]public async Task<PasteBuilderHelper.VoloModelInfo> ReadUpdateModel(int id){var _info = await _dbContext.WebsiteNotice.Where(x => x.Id == id).AsNoTracking().FirstOrDefaultAsync();if (_info != null && _info != default){var dto = ObjectMapper.Map<WebsiteNotice, WebsiteNoticeUpdateDto>(_info);var _dataModel = PasteBuilderHelper.ReadModelProperty<WebsiteNoticeUpdateDto>(dto);return _dataModel;}var _model = PasteBuilderHelper.ReadModelProperty<WebsiteNoticeUpdateDto>(new WebsiteNoticeUpdateDto());return _model;}/// <summary>/// 读取ListDto的数据模型/// </summary>/// <returns></returns>[HttpGet]public PasteBuilderHelper.VoloModelInfo ReadListModel(){var _model = PasteBuilderHelper.ReadModelProperty<WebsiteNoticeListDto>(new WebsiteNoticeListDto());var _query_model = PasteBuilderHelper.ReadModelProperty(new InputQueryWebsiteNotice());if (_query_model != null){_model.QueryProperties = _query_model.Properties;}return _model;}

注意看上面的，加了ListDto和InputQueryWebsiteNotice
InputQueryWebsiteNotice是什么鬼？

        /// <summary>/// 按页查询对象/// </summary>/// <param name="input"></param>/// <returns></returns>[HttpGet]public async Task<PagedResultDto<WebsiteNoticeListDto>> Page([FromQuery] InputQueryWebsiteNotice input){var _query = _dbContext.WebsiteNotice.Where(t => 1 == 1);var _pagedto = new PagedResultDto<WebsiteNoticeListDto>();if (input.page == 1){_pagedto.TotalCount = await _query.CountAsync();}var dataList = await _query.OrderByDescending(x => x.Id).Page(input.page, input.size).AsNoTracking().ToListAsync();if (dataList == null || dataList.Count == 0){throw new PasteSoftException("没有查询到数据", 204);}var temList = ObjectMapper.Map<List<WebsiteNotice>, List<WebsiteNoticeListDto>>(dataList);_pagedto.Items = temList;return _pagedto;}

看上面，知道了吧？说白点就是列表的时候的查询项！
啥玩意？？？咋查询搞里面去了？？？

查询支持

看最新的页面

上面是某一个表的对应的列表的页面，上面的信息中，处理下方的页码，上方的新增，查询和刷新按钮，其他的都是后端控制的！！！
对，是其他的所有的(表格的线不算哈！)，比如这个表对应有几个查询项，就是上面举例子的
InputQueryWebsiteNotice控制的！
以下是页面打开后第一次获取的数据模型数据

通过读取对应的Dto的内容，控制前端的UI
看下我的查询的模型

    /// <summary>/// 站点公告查询 站点公告的查询项/// </summary>public class InputQueryWebsiteNotice: InputSearchBase{/// <summary>/// 标题 点击键入基于标题查询/// </summary>[MaxLength(16)]public string title { get; set; } = "";/// <summary>/// 状态 默认值为-1表示不查询/// </summary>public int state { get; set; } = -1;/// <summary>/// 开关 基于开关类型查询/// </summary>public bool status { get; set; } = false;/// <summary>/// 开始日期/// </summary>public DateTime? sdate { get; set; } = null;/// <summary>/// 结束日期/// </summary>public DateTime edate { get; set; }}

如何给定其他属性，比如必填，默认值等？
其实只要和Dto一样，把对应的Attribute标注上去即可，数据模型的规则传递给前端后，前端根据规则生成UI即可！
这里有几个规定
对于DateTime类型，如果可为null的，也就是标注了 ?的则数据类型为DateTime ，其中required为false
如果不为Null类型的，则数据类型为DateTime,其中required为true

总结优势

那是不是意味着，一个项目的管理端可以做到只有4个页面！！！
1.登陆到页面
2.菜单页面
3.对应表的列表显示页面，显示表格数据等，兼顾外表的选择！
4.表单页面，兼顾新增，编辑
4个页面即可实现项目的后台管理端，涉及的功能包括不限于，图片上传等，数据列表展示，表单的新增和编辑，日期选择等！
关键点，页面的代码不多，比如我的表格数据页面的代码行才300行不到!
表单页面的代码才500行不到
我的测试页面有些规则还没有提取出来，比如数据项的格式校验等！

需要注意点

数据类型

由于涉及不同端，在数据类型上肯定有不一样的地方，比如后端的存储类型为string,在前端的表示就很多了，
比如昵称，签名内容，文章描述，文章内容，头像的地址，甚至日期等都可以使用string表示，这就需要一个协商，也就是转化，把后端类型转化，翻译成前端类型的函数，这个需要使用方自己实现，和后端协商一致即可！
比如我的规则，如果String类型，长度没有限制，则在前端翻译成richtext，如果长度小于128限定，则为text,如果长度>128则为textarea

指定类型

有些类型，后端没有，或者是没法表示，因为我们的原则是尽量后端控制前端，比如images，比如region，这就需要我们后端在模型上动手脚了！
比如我的一个案例

    /// <summary>/// 用于标记字段有查询的属性/// </summary>public class DataTypeAttribute : Attribute{/// <summary>/// /// </summary>private string Name { get; set; }/// <summary>/// /// </summary>public DataTypeAttribute(string _name = ""){Name = _name;}/// <summary>/// /// </summary>/// <returns></returns>public override string ToString(){return Name.ToString();}}

上面这个属性是自定义的，可以自己命名，后面前端基于这个进行处理即可，比如:

        /// <summary>/// 头像/// </summary>[DataType("image")]public string Head { get; set; }

这样前端在遇到这个字段的时候，读取到他的属性DataType为image,那么前端对这个字段进行渲染的时候，就使用image的类型来处理！
同样的道理，你可以实现更多的，比如单选，选项内容，等可以通过自定义的属性来实现！

写在最后

通过以上的思路，我们可以实现
1.安全，所有的属性信息是dto模块的，我们开放给前端的，前端才能够查询到
2.对模型的字段的规则，前后端都支持，前端是为了体验，后端是为了安全！
3.我们不需要为了新增一个字段而去修改前端了！

目前的代码还在完善中，后续我们会把这个功能添加到PasteTemplate(.netCore的WebApi项目模板)和PasteBuilder右键代码生成器中！

下期，作者将提供实际项目的案例展示，和其中做的一些处理等！