文章評論功能前後端實現方案總結

柒墨轩發表於2024-07-22
後端

效果圖：

（1）前端

1. 兩種方案

不同角色看到評論類別的操作是由不同的，比如，本人釋出的評論我們可以對其進行編輯和修改，且邏輯上不能舉報自己，所以在同一頁面實現不同顯示，我們就需要狀態量去控制不同頁面元素的顯隱。

在此，有兩種方案：

  1. 由前端設定狀態量，並透過後端的資料特徵維護這些狀態量，判斷結束後，前端就能實現不同情況的合理顯示。這種方案就是後端省事，前端需要自己做相當一部分事情去判斷，要麻煩一些。
  2. 資料驅動，傳入巢狀評論結構，給頁面渲染。即後端在返回前端評論資訊時，將這些狀態量一併返回。這種的好處就是前後端都相對方便，前端專注於狀態量判斷和顯示，後端專注於狀態量的維護，在後端維護是方便的，因為資料就是從此返回的。

2. 方案對比和總結

這兩種方案各有優劣，取決於具體的專案需求、團隊分工、效能考慮以及維護成本等因素。以下是對比這兩種方案的一些考慮因素：

方案一：前端設定狀態量，後端維護資料特徵

優勢：

  1. 前後端職責分明： 前端負責邏輯判斷和顯示，後端專注於資料維護。
  2. 前端自由度高： 前端可以更靈活地處理和呈現不同狀態，定製化程度較高。
  3. 效能最佳化： 前端可以根據需要靈活控制頁面的顯示邏輯，減輕後端負擔。

不足：

  1. 前端邏輯複雜： 前端需要處理複雜的狀態判斷和頁面顯示邏輯，可能增加前端開發難度。
  2. 可能涉及重複邏輯： 如果有多個地方需要類似的狀態控制，可能需要在多個地方重複實現相同的邏輯。

方案二：資料驅動，後端返回狀態量

優勢：

  1. 簡化前端邏輯： 前端只需要根據後端返回的狀態量進行簡單的判斷，減輕前端的邏輯複雜度。
  2. 統一資料來源： 所有狀態相關的資訊都來自後端，可以避免狀態不一致的問題。
  3. 後端靈活性： 後端可以更方便地修改狀態相關的邏輯，不需要修改前端程式碼。

不足：

  1. 前後端關聯緊密： 前端和後端的邏輯高度耦合，可能導致前後端開發難度增加，後端需考慮更多的前端邏輯。
  2. 效能考慮： 需要傳輸更多的資料到前端，可能增加網路傳輸成本。

綜合考慮：

  1. 專案需求： 如果專案對前端互動有較高的定製需求，方案一可能更適合。
  2. 團隊技術棧和分工： 如果團隊前端技術水平高，能夠輕鬆處理複雜邏輯，方案一可能更適合；如果後端能夠方便地維護狀態邏輯，方案二可能更適合。
  3. 效能需求： 如果對網路傳輸和前端效能有較高要求，方案一可能更合適。

在實際應用中，也可以綜合兩種方案，根據具體場景採取不同的策略，例如，簡單的狀態量由後端返回，複雜的邏輯由前端處理。

（2）後端

評論功能的關鍵點我認為是在於如何對評論的巢狀和父子關係進行合理的資料儲存。對於文章評論功能，可做出以下結構劃分。

  1. 文章-一級評論（父級評論）：即使用者對於文章做出的評論；
  2. 一級評論-二級評論（父-子評論）：即其他使用者對文章評論的評論，以及父級評論者對這些評論的回覆，簡而言之，就是評論者之間的互動，其實這裡已經與文章沒有關係了，因為互動的物件都是評論者了。

基於1、2，本文提出了兩種儲存方案予以處理。

1. 簡單方案

除文章表之外，只設計一張評論表：article_comment。

欄位包括：

  • articleId：文章id
  • senderId：傳送者id
  • receiverId：接收者id
  • comment：評論內容

具體實現如下：

  • receiveId為空時，表示該條評論是針對文章的，反之是針對評論者的。
  • 限制：同一個人只能對一篇文章做最多一條評論，才能確保這個三元組（articleId-senderId-receiverId）的唯一性，即他人對一個人的評論做出的評論才能保證唯一，且這種方案下，被評論者也無法對評論者進行回覆。侷限性還是蠻多的。且沒實現兩級評論的解耦（文章-評論；評論-評論）。
  • 不過，如果能容忍以上限制，那麼我們可以很簡單的實現一個簡單的評論功能。

2. 完備方案

第二種方案則能完備的突破簡單方案中的限制，實現完整的功能。

即，除文章表之外，設計兩張表：

  1. article_comment
    • 　　aarticleId：文章id
    • 　　buserId：評論者id
    • 　　ccallId：流水號，作為該條記錄的唯一標識
    • 　　dcomment：評論內容
  2. comment_relation
    • 　　auserId：評論者id
    • 　　bcomment：評論內容
    • 　　cself_callId：該條記錄的流水號，唯一標識
    • 　　dtarget_callId：評論的那條記錄的流水號，來源有兩個：1. article_comment表中的callId（父級評論的流水號）；2. comment_relation表中其他記錄的sefl_callId流水號.

透過這兩張表，我們就能實現，多級的評論和回覆。

  1. 為什麼用流水號而不用id：因為target_callId的來源有兩個表，用記錄id有可能會重複造成衝突。
  2. callId流水號是該方案的核心，必須保證其唯一性。
  3. 這種方案的好處是我們無需關注評論者的資訊如何如何，只需將流水號作為唯一標識即可，父級關係就用target和self區分即可。同時這種方案，實現瞭解耦，現在我們是文章評論，那麼如果我們換成歌曲的評論，我們只需改article_comment，而comment_relation是可以複用的，實現了評論與被評論之物的解耦。

3. 方案總結和對比

當對比兩種方案的好處時，我們可以著重考慮它們在可維護性、靈活性、效能以及擴充套件性方面的差異：

簡單方案的好處：

  1. 易實現和維護： 資料表結構相對簡單，易於實現和維護，前端和後端的開發相對較為輕鬆。
  2. 適用於簡單場景： 對於不需要多級評論和回覆的簡單場景，這種方案足夠滿足需求，減少了系統的複雜性。
  3. 效能最佳化： 由於資料表結構簡單，可能對資料庫的查詢和操作有一定的效能優勢。

完備方案的好處：

  1. 多級評論和回覆的支援： 這是該方案的核心優勢，可以實現更豐富的評論互動，提高使用者體驗。
  2. 解耦性強： 透過兩張表的設計，實現了評論與被評論之物的解耦。對於不同的被評論物件（例如文章、歌曲等），只需修改一張表而另一張表可以複用。
  3. 靈活擴充套件： 由於流水號的設計，方便擴充套件和修改評論系統的其他功能，如點贊、舉報等。
  4. 更高的定製化： 具備更高的定製化程度，適用於複雜的業務場景，滿足更多需求。
  5. 可複用性： 評論關係表(comment_relation)的設計使得該方案更容易在不同模組中複用，例如可以用於其他社互動動。

綜合對比：

  • 簡單方案適用於： 簡單的評論系統，不需要多級回覆的情況，且對資料庫設計和維護要求較低。
  • 完備方案適用於： 複雜的評論系統，需要支援多級評論和回覆，並且對系統的擴充套件性、定製化程度有較高要求。

總體來說，選擇哪種方案應該根據具體的業務需求、系統規模和團隊技術水平來決定。在簡單場景下，可以選擇簡單方案，而在對評論系統有更多要求的情況下，完備方案可能更為合適。

相關文章