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右键代码生成器中！
下期，作者将提供实际项目的案例展示，和其中做的一些处理等！
