介绍
schema
# 再解crud
基于我之前做的一个crud的东西(已经有了好多个版本了。。)，从目前来讲，crud大概就几种，第一种是直接生成模板，本质上没有任何封装，这个二改起来当然是最容易的，但近乎必须要改，不可能直接用，第二种是极致的封装，比如一些低代码的东西，定了表结构就完事了，第三种介于两者之间，(可能)在路由处进行操作，如果是express就是通过配置生成中间价，如果是nest直接通过装饰器就好
我慢慢反应过来，无论是哪一种，都倾向于从表的结构去映射接口，无非就是映射与规则的区别，也就是一个表映射出一批接口，通过规则去筛选属性或者增加守卫等
实际上，先不说表结构不可能这么单纯，就说我一个前端，我关心表结构干什么呢。我其实真正关心的应该是切口的结构才对。
# 切口
所谓切口，可以是一个到一个模块的传输过程，比如调用组件时的props，这其中最重要的，就是前端向后端传数据这一切口(相当于这个切口中的一部分并不在我的管理范围)，我至少应该基于这个去搞，由切口，去回过头，可选地映射前端结构和表结构，就是说，在有切口结构后，根据规则映射表单或者数据表，这个好处在于，基于数据表去映射的crud，一是规则极其难搞，先要映射到service，再要映射到controller的验证，再要映射中间件，最后映射前端表单，经过的环节有点太多了，二是一旦表结构不那么单纯的时候，整个东西什么都产生不了，基于接口去映射的话，到前端只需要一次映射，到中间件，数据表都只是一次(基于数据表那种也可以一次，但那样逻辑上就不是连接的)，就算三种映射全都失败，接口本身，也是可以用于验证的
# 计划
我现在做了一个headless的json schema的东西，通过配置去制定映射的规则，有点像strapi，希望能一劳永逸解决这个问题
目前已经并入视图引擎，和属性表单引擎共同构成schema方案（现在先叫他服务规则引擎吧）