ПередмоваПоки що я виконав два-три проєкти, включно з освітою, форумами та CMS, і кожен проєкт використовує функцію коментарів, тому я хочу окремо видалити розділ коментарів і зробити його компонентованим модулем. Це не лише економить розробку, а й дозволяє краще зрозуміти функції цього модуля. Оскільки я наразі переважно розробляю з використанням фреймворку TP, у синтаксисі фреймворку TP будуть наведені наступні приклади. Але насправді я особисто вважаю, що основний метод недостатній, і я не використовував функцію моделі асоціацій. Ось що я впроваджу в наступному оновленні. У головній частині я розповім вам про різні режими систем коментарів, з якими я вже стикнувся, проаналізую їхні переваги та недоліки, а також поділюся уявленням про дизайн таблиць даних і вилучення даних, сподіваючись бути корисним для вас. Якщо є щось недоречне, кожен також може це виправити.
Система коментарів
Існує три основні типи поширених систем коментарів: будівництво в будівлі, режим стрімінгу та режим цитування (усі з яких я назвав своїми іменами), і наступне присвячене перевагам і недолікам цих трьох та способам їх реалізації.
1. Режим будівництва в будівлі Так звана будівля в моделі будівлі означає, що кожен коментар займає перший поверх, і всі відповіді на нього відображаються в будівлі, наприклад, система коментарів Baidu Tieba та Jianshu.
Перевага:Відповідайте на коментарі сфокусованим поглядом, який полегшує розуміння розмови, яку вони викликають.
Недоліки:Коли контенту занадто багато, потрібно зробити пагінацію, що є складнішим.
Дизайн технічних характеристик:
- id (самододаний первинний ключ)
- target_id (ID теми коментаря, який можна змінювати на article_id, course_id тощо за потреби)
- parent_id (ID головного коментаря)
- reply_uid (Записати ідентифікатор користувача коментаря, 0 при відповіді на основний коментар)
- UID (User ID, який залишив коментар)
- Контент (Коментарі)
- Інші сфери... (Час, статус тощо)
Бекенд-логіка бізнесу:
2. Режим потоку
Режим потоку, як випливає з назви, схожий на потік інформації — чи то коментар, чи відповідь, кожне повідомлення займає шар, наприклад, система коментарів спільноти laravel-China.
Перевага:Логіка проста і легка для реалізації
Недоліки:Зміст діалогу не можна подати централізовано, і зрозуміти його зміст нелегко.
Дизайн технічних характеристик:
- id (самододаний первинний ключ)
- target_id (ID теми коментаря, який можна змінювати на article_id, course_id тощо за потреби)
- reply_uid (Записати ідентифікатор користувача коментаря, 0 при відповіді на основний коментар)
- UID (User ID, який залишив коментар)
- Контент (Коментарі)
- Інші сфери... (Час, статус тощо)
Бекенд-бізнес-логіка
3. Режим цитування
Режим цитування схожий на режим стрімінгу, за винятком того, що зміст відповіді публікується разом із цитованим контентом.
Перевага:Розуміння, на який коментар спрямована відповідь, допоможе вам зрозуміти, про що йдеться в розмові. Його відносно легко реалізувати.
Недоліки:Подібно до Stream Mode, він не відображає всю розмову повністю. Аналізуючи переваги та недоліки, можна з'ясувати, що еталонний патерн є компромісом між будівлею всередині будівлі та режимом потоку.
Дизайн технічних характеристик:
- id (самододаний первинний ключ)
- target_id (ID теми коментаря, який можна змінювати на article_id, course_id тощо за потреби)
- reply_id (ID коментаря коментаря, головний коментар — 0)
- UID (User ID, який залишив коментар)
- Контент (Коментарі)
- Інші сфери... (Час, статус тощо)
Бекенд-логіка бізнесу:
Щоб отримати список відгуків, можна підключити таблицю коментарів, щоб отримати інформацію про користувачів і коментарі, які цитують ці коментарі. Потім виконайте простий процес пагінації.
Вищенаведено попереднє резюме трьох режимів коментарів, стильова частина ще не вирішена, а після завершення блог-проєкту також буде додано фронтенд-стиль. Щодо вищезазначеного контенту, якщо є якісь недоліки, сподіваюся, ви надасте поради.
|