前言

回顧上一節，我們熟悉的了解了消息的請求和響應，這一節我們來建立數據庫的表，表的設計蠻復雜

你也可以按自己所分析的情形結構來建表

必須非常熟悉表的結果才能運用這張表，這表表的情形涵蓋比較多

思維導圖

我這個人比較喜歡用思維導圖來分析和表達一些模型：

?

表結構

根據思維導圖，我們可以建立的表可以是3張表：消息表，規則表，類型表

消息表：實際的消息

規則表：文本、圖文、語音等

類型表：文本、圖文、語音（默認回復，訂閱回復）

也可以是兩張表：規制表，消息表（+一個類型字段）

我這里只設計一張表：消息表（+一個規則字段+一個類型字段）

設計表結構與個人的平時習慣有關系，我還是喜歡簡單的東西，別為了設計而去專門設計，這樣只會增加系統的復雜度

CREATE TABLE [dbo].[WC_MessageResponse]([Id] [varchar](50) NOT NULL, --主鍵 [OfficalAccountId] [varchar](50) NULL, --所屬公眾號[MessageRule] [int] NULL, --消息規則（枚舉）[Category] [int] NULL, --類型（枚舉）[MatchKey] [varchar](1000) NULL, --關鍵字[TextContent] [varchar](max) NULL, --文本內容[ImgTextContext] [varchar](max) NULL, --圖文文本內容[ImgTextUrl] [varchar](1000) NULL, --圖文圖片URL[ImgTextLink] [varchar](1000) NULL, --圖文圖片超鏈接[MeidaUrl] [varchar](1000) NULL, --語音URL[MeidaLink] [varchar](1000) NULL, --語音超鏈接[Enable] [bit] NOT NULL, --是否啟用[IsDefault] [bit] NOT NULL, --是否默認[Remark] [varchar](2000) NULL, --說明[Sort] [int] NOT NULL, --排序[CreateTime] [datetime] NOT NULL, --創建時間[CreateBy] [varchar](50) NOT NULL, --創建人[ModifyTime] [datetime] NOT NULL, --修改時間[ModifyBy] [varchar](50) NULL, --修改人CONSTRAINT [PK_WC_MessageResponse] PRIMARY KEY CLUSTERED ([Id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]GOSET ANSI_PADDING OFF GOALTER TABLE [dbo].[WC_MessageResponse] WITH CHECK ADD CONSTRAINT [FK_WC_MessageResponse_WC_OfficalAcconts] FOREIGN KEY([OfficalAccountId]) REFERENCES [dbo].[WC_OfficalAccounts] ([Id]) ON DELETE CASCADE GOALTER TABLE [dbo].[WC_MessageResponse] CHECK CONSTRAINT [FK_WC_MessageResponse_WC_OfficalAcconts] GO

表對應了兩個枚舉和關聯主表公眾號管理的主表

?公眾號管理在70節

對應的枚舉

public enum WeChatReplyCategory{//文本Text =1,//圖文Image =2,//語音Voice =3,//相等，用于回復關鍵字Equal=4,//包含，用于回復關鍵字Contain = 5}public enum WeChatRequestRuleEnum{/// <summary>/// 默認回復，沒有處理的/// </summary>Default =0,/// <summary>/// 關注回復/// </summary>Subscriber =1,/// <summary>/// 文本回復/// </summary>Text =2,/// <summary>/// 圖片回復/// </summary>Image =3,/// <summary>/// 語音回復/// </summary>Voice =4,/// <summary>/// 視頻回復/// </summary>Video =5,/// <summary>/// 超鏈接回復/// </summary>Link =6,/// <summary>/// LBS位置回復/// </summary>Location =7,}

枚舉其實對應就是我省掉的其余兩張表

到這里，相信表的設計已經非常清晰

后臺代碼

增刪改查非常普通，主要關注點在前端，前端處理提交的消息中，必須包含規則，類型，來指定消息的最終表達

?Controller ?BLL ?DAL

DAL層有必要來說明一下

默認回復和關注回復有3種類型：文本，圖文，語音（但是只能有一種，所以有IsDefault字段來表明執行哪種回復）所以這兩個規則必須另外處理，且看DAL的代碼執行的SQL語句便明白。

所以我們盡情的設計前端吧！

前端如何設計？

我們來看一個思維導圖：

?

前端完整代碼

?View Code

利用前端的思維導圖，來快速理解前端代碼，和應用于實際

總結

消息的管理是非常有技巧的一件事

1.消息在沒有任務回復的情況 下，我們應該啟用默認回復，要不用戶會得不到回應，丟失體驗

2.關鍵字的設計一般是一環扣一環，是有引導作用的

? ?比如：關鍵字：（我要） ? 回復： 按1加入獲得禮品一份，按2直接獲得50元

　　　　關鍵字：（1） ? ? ? 回復： 按3獲得鐵觀音茶一份，按4獲得普洱茶

　　　　關鍵字：（3或4） ?回復：請回復您的地址和電話及收件人

? ?這樣我們將獲得系統與用戶之間的完整對話，當然我們也要對用戶最后的信息進行處理

參考代碼：https://yunpan.cn/cM9ffkutawueD ?訪問密碼 2f0d

轉載于:https://www.cnblogs.com/syg1/p/5870886.html

總結

以上是生活随笔為你收集整理的ASP.NET MVC5+EF6+EasyUI 后台管理系统（73）-微信公众平台开发-消息管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。