正文
接口开发中,会碰到这种场景:用户可以评论一个人,也可以多篇文章,相应的要记录被评论人。
这种场景可能的提交接口数据举例记录一下:
// 评论单个人
$data = [
'committer_id' => 23, // 评论人
'receiver_id' => 101, // 被评论人
'content' => '评论内容',
];
// 评论多篇文章
$data = [
'committer_id' => 23, // 评论人
'content' => '评论内容',
'lists' => [
[
'post_id' => 101, // 文章id
'receiver_id' => 231, // 被评论人
],
[
'post_id' => 103,
'receiver_id' => 151,
],
[
'post_id' => 135,
'receiver_id' => 157,
],
],
];
现在可以看到代码处理时,数据结构决定的差异还是挺大的(被评论人的处理上)。
首先想到这种结构:
// 评论单个人
$data = [
'committer_id' => 23, // 评论人
'content' => '评论内容',
'lists' => [
[
'receiver_id' => 101, // 被评论人
],
],
];
// 评论多篇文章
$data = [
'committer_id' => 23, // 评论人
'content' => '评论内容',
'lists' => [
[
'post_id' => 101, // 文章id
'receiver_id' => 231, // 被评论人
],
[
'post_id' => 103,
'receiver_id' => 151,
],
[
'post_id' => 135,
'receiver_id' => 157,
],
],
];
现在代码可以共用了,但是只评论单个人时,这样提交数据,处理起来很累赘,业务数据的结构看起来也不清晰。
顺势而出,现在可以发现比较好的数据结构了:
// 评论单个人
$data = [
'committer_id' => 23, // 评论人
'receiver_id' => 101, // 被评论人
'content' => '评论内容',
];
// 评论多篇文章
$data = [
'committer_id' => 23,
'receiver_id' => 0,
'content' => '评论内容',
'lists' => [
[
'post_id' => 101,
'receiver_id' => 231,
],
[
'post_id' => 103,
'receiver_id' => 151,
],
[
'post_id' => 135,
'receiver_id' => 157,
],
],
];
总结一下:就是把父子结构共有的属性在父结构中赋值一下,这种数据结构处理起来逻辑比较明晰,而且也包含了另一种可能性:
// 同时评论单个人、多篇文章
$data = [
'committer_id' => 23,
'receiver_id' => 101,
'content' => '评论内容',
'lists' => [
[
'post_id' => 101,
'receiver_id' => 231,
],
[
'post_id' => 103,
'receiver_id' => 151,
],
[
'post_id' => 135,
'receiver_id' => 157,
],
],
];