评论系统架构设计--开发总结

小渣渣

前言目前为止，做了两三个项目，有涉及教育的、论坛的、CMS的，每个项目里都有用到评论这个功能，所以我就想把评论这一块，单独拿出来，做成一个组件化的模块。既节约了开发的工作，还能让自己对这个模块的功能有更进一步的理解。
因为目前我主要是用tp框架在做开发，所以以下相关实例会以tp框架的语法来呈现。但其实核心方法部分我个人是觉得有所不足的，没有把关联模型的功能给利用起来。这块是我下一版更新的时候会实现的部分。
正文部分，主要会给大家讲讲目前接触到的评论系统的几种模式，分析他们各自的优劣势，并提供一个数据表设计以及数据提取的思路，希望对大家能够有所帮助。如有不当之处，也欢迎大家拍砖指正。

评论系统

常见的评论系统主要有三种：楼中楼模式、 流模式 和引用模式 （都是我自己起的名字），下面集中介绍这三种的优劣势以及实现方法。

一、楼中楼模式
所谓楼中楼模式，就是每条评论占一楼，针对该评论的所有回复都在该楼里展现，比如百度贴吧、简书的评论系统。




优势：回复评论的内容集中展现，易于了解评论引发的对话。
劣势：内容过多时需要做分页处理，较为复杂。
数据表设计：

• id（自增主键）
• target_id （评论主题的id，可根据需要修改为article_id、course_id等等）
• parent_id(主评论id）
• reply_uid (记录被评论的用户id，回复主评论时可以0）
• uid（发表评论的用户id）
• content （评论内容）
• 其他字段… （时间、状态等）
  

后端业务逻辑：

登录可见。

二、流模式

流模式，顾名思义，展现形式类似于信息流，不管是评论还是回复，每条信息都占一层，比如laravel-china社区的评论系统。




优势： 逻辑简单，实现较为容易
劣势： 对话内容不能集中呈现，不便于了解对话内容。
数据表设计：

• id（自增主键）
• target_id （评论主题的id，可根据需要修改为article_id、course_id等等）
• reply_uid (记录被评论的用户id，回复主评论时可以0）
• uid（发表评论的用户id）
• content （评论内容）
• 其他字段… （时间、状态等）
  

后端业务逻辑

登录可见。

三、引用模式

引用模式与流模式相似，只是回复的内容发布时会带上引用的内容。




优势：可以理解回复针对的是哪条评论，有助于了解对话内容。实现相对容易。
劣势：与流模式相似，不能完整呈现整个对话内容。 通过分析优劣势可以发现，引用模式是介于楼中楼以及流模式之间的一个折中方案。
数据表设计：

• id（自增主键）
• target_id （评论主题的id，可根据需要修改为article_id、course_id等等）
• reply_id(被评论的评论id，主评论为0）
• uid（发表评论的用户id）
• content （评论内容）
• 其他字段… （时间、状态等）
  

后端业务逻辑：

获取评论列表可以通过左连接评论表，获取引用评论的用户信息和评论等内容。再做简单的分页处理就可以了。

登录可见。

以上是针对三种评论模式的初步总结，对于样式部分还没有进行整理，等完成博客项目后，会把前端样式的部分也加上。而对于以上的内容，如有不足之处，希望大家提出指导。

BennyTian

您好 看到您的评论系统的帖子  受益匪浅  目前自己也正准备做一个评论系统  数据量大概10亿级别  日访问量100w+  想请教一下设计相关的问题,  要是方便的话, 能否加一下您的微信?  我的微信是 BennyTian  ,  感谢 !!!