ASP.NET MVC5+EF6+EasyUI 後臺管理系統（73）-微信公衆平臺開發-消息管理

前言

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

你也能夠按本身所分析的情形結構來建表

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

思惟導圖

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

 

表結構

根據思惟導圖，咱們能夠創建的表能夠是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]

GO

SET ANSI_PADDING OFF
GO

ALTER TABLE [dbo].[WC_MessageResponse]  WITH CHECK ADD  CONSTRAINT [FK_WC_MessageResponse_WC_OfficalAcconts] FOREIGN KEY([OfficalAccountId])
REFERENCES [dbo].[WC_OfficalAccounts] ([Id])
ON DELETE CASCADE
GO

ALTER 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