先看下商品分类的表结构

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的差异会更明显