前言
- 单一规则搞开发体验,快速开发。
- 尽量少的约定来减少沟通
- 更高的扩展。
- 写成文章顺便思考对比这个问题
开始对比两种风格
风格一
- 避免了JPA LAZY的处理,问题是返回了不同了实体,导致结构不统一,使用端需要进行思考。JSON格式如下:
//普通类别及普通关联级查询
GET users?page=0&size=1
[{
"id":1;
name:"nick name"
}]
//坏处:用户详情,带来了结构的变化,在添加和修改时造成,使用方需要调整json结构
GET users/details?page=0&size=1
[{
enable:true,
userRoles:["admin","tester"]
user:{
"id":1;
name:"nick name"
}
}]
//好处:在Spring boot JPA开发体验上有所提示,不在需要关注Lazy 或 EAGER。Details 就是eager, users就是lazy
//添加时,查询与修改格式完全不统一导致不舒服
POST users/details/add
{
name:"xxxx",
userRoles:["admin"],
enable:true
}
风格2
//普通类别及普通关联级查询,lazy. 问题是数据里存在 空实体,不管恶心,管了需要加VO增加代码量。
GET users?page=0&size=1
[{
"id":1;
name:"nick name",
userDetail:null,
userRoles:[]
}]
//eager: 保持了不变的风格。让使用方更加明白,实体之间的关系。需要后段对eager 字段进行控制。
GET users/details?page=0&size=1
[{
"id":1;
name:"nick name",
userDetail:{enable:ture},
userRoles:["admin"]
}]
//添加时,查询与修改格式 一致,减少了约定
POST users/details/add
{
name:"xxxx",
userRoles:["admin"],
userDetail:{enable:true}
}
总结
- 为了可以长期舒服使用,后段还是辛苦点好。风格2 更加适合长期开发约定。
网友评论