forordSå langt har jeg gjort to eller tre prosjekter, inkludert utdanning, forum og CMS, og hvert prosjekt bruker kommentarfunksjonen, så jeg vil fjerne kommentarfeltet separat og gjøre det om til en komponentbasert modul. Det sparer ikke bare utviklingsarbeid, men gir deg også en bedre forståelse av funksjonene i denne modulen. Siden jeg for øyeblikket hovedsakelig utvikler med TP-rammeverket, vil følgende eksempler bli presentert i syntaksen til TP-rammeverket. Men faktisk føler jeg personlig at kjernemetoden er utilstrekkelig, og jeg har ikke benyttet meg av funksjonen til assosiasjonsmodellen. Dette er hva jeg vil implementere i neste oppdatering. I hovedsak vil jeg fortelle om de ulike måtene av kommentarsystemer jeg har vært eksponert for så langt, analysere deres respektive fordeler og ulemper, og gi en idé om design av datatabeller og datautvinning, i håp om å være til hjelp for deg. Hvis det er noe upassende, er alle også velkomne til å rette det.
Kommentarsystem
Det finnes tre hovedtyper felles kommentarsystemer: bygging innenfor en bygning, strømmingsmodus og siteringsmodus (alle disse har jeg gitt mine egne navn), og det følgende fokuserer på fordeler og ulemper ved disse tre og hvordan man implementerer dem.
1. Bygning-i-en-bygning-modus Den såkalte bygning-innen-en-bygning-modellen betyr at hver kommentar opptar første etasje, og alle svar på kommentaren vises i bygningen, slik som kommentarsystemet til Baidu Tieba og Jianshu.
Fordel:Svar på kommentarer med et fokusert blikk som gjør det lett å forstå samtalen de starter.
Ulemper:Når det er for mye innhold, må det være paginering, som er mer komplisert.
Databladdesign:
- id (selvlagt primærnøkkel)
- target_id (ID for kommentaremnet, som kan endres til article_id, course_id osv. etter behov)
- parent_id (hovedkommentar-id)
- reply_uid (Registrer bruker-ID-en til den kommenterte, 0 når du svarer på hovedkommentaren)
- UID (Bruker-ID som la igjen kommentaren)
- innhold (Kommentarinnhold)
- Andre felt... (Tid, status, osv.)
Back-end forretningslogikk:
2. Flytmodus
Flytmodusen, som navnet antyder, ligner på informasjonsflyten, enten det er en kommentar eller et svar, hver melding har et lag, som kommentarsystemet til laravel-China-fellesskapet.
Fordel:Logikken er enkel og lett å implementere
Ulemper:Innholdet i dialogen kan ikke presenteres sentralt, og det er ikke lett å forstå innholdet i dialogen.
Databladdesign:
- id (selvlagt primærnøkkel)
- target_id (ID for kommentaremnet, som kan endres til article_id, course_id osv. etter behov)
- reply_uid (Registrer bruker-ID-en til den kommenterte, 0 når du svarer på hovedkommentaren)
- UID (Bruker-ID som la igjen kommentaren)
- innhold (Kommentarinnhold)
- Andre felt... (Tid, status, osv.)
Back-end forretningslogikk
3. Siteringsmodus
Siteringsmodus ligner på strømmemodus, bortsett fra at innholdet i svaret publiseres sammen med det siterte innholdet.
Fordel:Å forstå hvilken kommentar svaret er rettet mot, kan hjelpe deg å forstå hva samtalen handler om. Det er relativt enkelt å implementere.
Ulemper:På samme måte som Stream Mode representerer den ikke hele samtalen i sin helhet. Ved å analysere fordeler og ulemper kan man finne at referansemønsteret er et kompromiss mellom bygningen innenfor bygningen og flytmodusen.
Databladdesign:
- id (selvlagt primærnøkkel)
- target_id (ID for kommentaremnet, som kan endres til article_id, course_id osv. etter behov)
- reply_id (kommentar-ID for kommenterte, hovedkommentar er 0)
- UID (Bruker-ID som la igjen kommentaren)
- innhold (Kommentarinnhold)
- Andre felt... (Tid, status, osv.)
Back-end forretningslogikk:
For å få listen over anmeldelser kan du koble kommentartabellen for å få brukerinformasjonen og kommentarene som siterer kommentarene. Deretter gjør du en enkel pagineringsprosess.
Ovenfor er en foreløpig oppsummering av de tre kommentarmodusene, stildelen er ennå ikke løst, og etter at bloggprosjektet er fullført, vil også front-end-stildelen bli lagt til. Når det gjelder innholdet ovenfor, hvis det er noen mangler, håper jeg du vil gi veiledning.
|