MongoDB實現評論榜
- 2019 年 10 月 3 日
- 筆記
Mongodb很適合做這件事,api的調用僅僅是使用到了入門級別的CRUD,理清楚了思路,編碼也會順風順水,所以你會發現我在這篇博客中說的比編碼還多
評論榜預期的功能
就像是StackOverFlow的那樣, 用戶可以發出自己的提問,其他用戶來解答, 同時樓主可以回復別人的評論,別人依然可以回復樓主
數據結構
mongodb可以存儲文檔啊, 其實我們要做的就是構建一個合適的類,評論幫也就成功一大半了
問題/ 評論 實體如下
問題
public class Problem implements Serializable { @Id private String _id;// key private String nickname; // 用戶名 private String avator; // 用戶頭像 private String userId; // 戶名id private String title ; // 標題 private String content ; // 內容 private boolean answered ; // 是否已經回答 private Date createTime ; // 創建時間 private boolean flag =false; // 標記是否是本人,默認是非本人 private List<Answer> answerList; // 問題的回答列表 }
評論
public class Answer { private String id;// 當前回答的唯一標識 private String nickname; // 用戶名 private String avator; // 用戶頭像 private Integer userId; // 回答的用戶的id private String Content ; // 回答的內容 private Date time; private boolean flag = false;// 默認false.不是本人 private Integer group; // 分組的標記 }
思路
Answer實體中,並沒有添加一個集合用來存放Answer類型的實體,如果添加上這個集合的話,確實想法還不錯,回復中有其他人對自己的回復,天生的樹形結構,但是考慮到前端的渲染的難度加大,放棄了這種方案
問題的實體類中維護了一個回答的實體類的集合,所有針對樓主問題的回答實例全部放在這個集合中, 也包括樓主對問題回答者的回復, 還包含回答者對問題的回復
於是這樣就僅僅存在兩層,一個問題中維護着對這個問題的全部回復,前端渲染的難度大大降低,但是後來卻來事了
用戶查詢一個問題的詳情時,後端如何處理
當用戶查詢一個問題的詳情時,後端拿着問題的id,去數據庫中將問題的實例取出來,緊接着處理Answer集合,將按照時間排序的集合按照我們指定的方式分組,再按時間排序
按什麼分組呢?
當時是按照不同的用戶分組, 同一個用戶的全部評論,已經樓主對它的回復,以及別人對它的回復都放在一起, 所以需要一個字段,group(我選的用戶id), 專門存儲分組的標誌. 組內的實例再按照時間排序,這樣整體的層次就劃分好了
public JsonResult problemDetail(@PathVariable String problemId){ Optional<Problem> byId = problemRepository.findById(problemId); if (!byId.isPresent()){ return JsonResult.fail("您沒有獲取到詳情頁,請聯繫管理員"); } Problem problem = byId.get(); if (problem.getAnswerList().size()>0){ Map<Integer, List<Answer>> collect = problem.getAnswerList() .stream().collect(Collectors.groupingBy(Answer::getGroup)); ArrayList<Answer> list = new ArrayList<>(); collect.forEach((k,v)->{ list.addAll(v); }); problem.setAnswerList(list); } return JsonResult.ok("返回詳情頁"+problem); }
定位出當前用戶的評論
如果前端想在頁面的分左右兩部分展示自己的評論和別人的評論,就需要一個標記,既然上面都已經在遍歷了,多加一個判斷也無妨, 拿着前端提交過來的用戶id和Answer中的userId比對, 如果相等,就把這個評論的flag標記為true, 前端根據這個標記區分, 從而給用戶更多的權限,比如刪除自己的評論
???局限性???
如果沒個問題都像網易音樂那種,上萬條評論,這樣的話,估計就廢了,雖然使用stream會快,但是也扛不住量啊, 但是數量小的話,還是可以接受的, 其實理想的狀態是評論可以以分頁的形式獲取出來, 感覺才正宗
2019/9/13 補充
發現了一個新的原生查詢語句, 可以限制查詢對象中數組的長度,以及查詢範圍
感興趣可以看這個連接 https://blog.csdn.net/leshami/article/details/55049891