先看下商品分类的表结构
CREATE TABLE `yoshop_category` (
`category_id` int unsigned NOT NULL AUTO_INCREMENT COMMENT '商品分类ID',
`name` varchar(50) NOT NULL DEFAULT '' COMMENT '分类名称',
`parent_id` int unsigned NOT NULL DEFAULT '0' COMMENT '上级分类ID',
`image_id` int unsigned NOT NULL DEFAULT '0' COMMENT '分类图片ID',
`status` tinyint unsigned NOT NULL DEFAULT '1' COMMENT '状态(1显示 0隐藏)',
`sort` int unsigned NOT NULL DEFAULT '0' COMMENT '排序方式(数字越小越靠前)',
`store_id` int unsigned NOT NULL DEFAULT '0' COMMENT '商城ID',
`create_time` int unsigned NOT NULL DEFAULT '0' COMMENT '创建时间',
`update_time` int unsigned NOT NULL DEFAULT '0' COMMENT '更新时间',
PRIMARY KEY (`category_id`),
KEY `store_id` (`store_id`)
) ENGINE=InnoDB AUTO_INCREMENT=10018 DEFAULT CHARSET=utf8mb3 COMMENT='商品分类表';
和商品分类相关的接口
image.png
都是单表操作，所以SQL都很简单
查询列表
image.png
商品分类是个树状结构，所以增加了一个function节点，根据 parent_id 组装子节点
image.png
接口返回的数据结构：
image.png
创建分类：
image.png
更新分类
image.png
删除分类
image.png
至此一个标准的CRUD接口就开发完成了，编码、调试、部署在同一个界面完成，相比传统开发方式的效率提升还是很明显的
不爽的地方
在创建和更新的时候，前端传过来的值都在 form 的嵌套属性中，但有时候会携带一些数据库无关的属性。直接通过knex的 insert(msg.req.body.form) 时会报错
谨慎起见需要用 _.pick(msg.req.body.form, ["prop1", "prop2", ...]) 挑选出用到的属性
这也是knex和其他orm框架相比不够贴心的地方，需要对操作的属性细心呵护，缺少对属性的校验和类型转换支持，不支持模型层面的查询scope，所以在 萤火商城 里基本每个查询sql基本都要带着 store_id = 10001 的条件
而且后面涉及到各种关联查询的时候，knex和orm的差异会更明显
