微信公衆平台應用開發架構sophia設計不足

設計一個小架構考慮的東西真不少，每一樣都不容易：

1、既要解決目前技術的不足；

2、又要友善他人使用（主要的目的）；

3、同時又要設計得優雅，容易擴充；

sophia一開始設計用來支援智能回複（文本可以帶參數的回複），後來又支援菜單，并統一了菜單和文本指令的處理邏輯，

再後來看到微信用戶端的互動元素太少，又支援html頁面操作和微信用戶端的會話（即頁面操作可以知道是哪個微信号操作的）

對于如何維系兩個不同類型消息（指令）之間的關系？對sophia來說有點吃力。即，前面是一個文本（指令），後面是一個其他類型的消息。

比如，某街道辦讓我們開發一個居民登記公衆平台，主要流程如下：

1、訂閱者輸入：登記

2、公衆平台提示：請輸入姓名：

3、訂閱者輸入：張三

4、公衆平台提示：輸入身份證号碼：

5、訂閱者輸入:xxxxxxxxxxxxxxxxxx

6、公衆平台提示：請上傳免冠相片：

7、訂閱者上傳相片。

8、公衆平台提示：登記成功！

訂閱者經過多次文本輸入和圖檔上傳後，公衆号如何保證前面的文本資訊和最後的圖檔是同一個人的？

如果看了sophia的源代碼和設計後（參閱我前面的文章）會發現sophia無法做到？因為我一開始就把sophia設計為處理文本消息的架構。

現在，如果要解決這個問題，那麼：

1、首先把所有的消息（文本、視訊、語音、圖檔、地理位置等，或者說每種互動）都認為是一種指令，讓架構都有機會處理；

2、其次要修改會話管理邏輯；

插播：

消息的多樣性：指同一種類型的消息，可以根據内容來解析出不同的指令，比如文本消息具有這個特性。

像圖檔無法解析出不同的内容，是以沒有多樣性（用圖像識别、語音識别技術除外）。這個概念會影響我們的設計。

1、由于文本消息具有多樣性，其對應的指令類就可以有不同的子類型。而非文本消息，隻能有一個指令類，合适嗎？

2、如果把非文本消息作為文本消息的特殊類型，又如何？

初步考慮擴充将文本指令類增加一個标記（支援後繼是非文本消息繼續處理），如果公衆平台收到非文本指令時候要檢查一下session中是否存在文本指令對象是否支援後繼非文本消息處理，然後調用此對象繼續處理。