整合微信小程序的Web API接口層的架構設計

在我前面有不少篇隨筆介紹了Web API 接口層的架構設計，以及對微信公衆號、企業號、小程序等模塊的分類劃分。例如在《C#開發微信門戶及應用(43)--微信各個項目模塊的定義和相互關係》介紹了相關模塊的劃分，在《基於微信小程序的系統開發準備工做》介紹了Web API的架構設計思路。本篇隨筆對以前介紹的架構內容進行統一的調整更新，以便更加方便實際項目的應用開發，以期達到統1、重用、清晰的目的。

一、公衆號、企業號、小程序模塊的劃分

咱們知道，目前微信企業應用，分爲公衆號、企業號（企業微信）、小程序三種應用模式，對於常規的開發來講，咱們對每一個模式的應用都分爲了兩個不一樣的部分，一個是和業務數據相關的數據管理、一個是和API接口相關的API管理，二者整合爲一個完整的應用。

公衆號、企業號（企業微信）、小程序三種應用模式的模塊劃分以下圖所示。

業務數據管理模塊，通常還須要調用API接口進行相關的處理操做，所以他們之間的項目引用關係以下所示

另外，這三種類型的API接口也公用了一些業務對象和實體類，所以把它們抽取出來做爲公共項目模塊，如這三類接口項目統一使用了一個公共實體類項目。

除了這些以外，咱們作項目，通常還涉及到一些基礎功能模塊，如公用類庫，以及附件管理、通信錄管理、權限管理模塊等內容，咱們能夠把後者幾個模塊放在一塊兒，組成基礎模塊。

 

二、基於微信的Web API 架構設計

隨着基於JSON格式的Web API的普遍應用，愈來愈多的企業採用Web API接口服務層，做爲統一接口的核心所在，也成爲Web API核心層。基於JSON格式的接口，能夠普遍地、跨平臺的應用於IOS、安卓等移動端，也能夠應用在常規的Web業務系統，Winform業務系統、微信應用、微信小程序等方方面面，所以企業內部造成本身是的一套Web API標準和詳細的文檔很是重要，一旦完善了，就能夠供各個業務場景使用，這些業務能夠外包給其餘軟件公司或者團隊，各自分離開發，而本身內部則只須要花費精力來統一維護Web API核心層和提升整個核心層的功能接口穩定、緩存處理等方面事情便可。其餘業務團隊開發的系統只須要遵循整個大接口平臺的統一規劃，完成各自的功能需求便可，不會形成數據庫的不一致，更不會讓某家公司掌握核心的技術資源，尾大不掉的尷尬情形。

基於上面的分析，咱們企業最終圍繞着Web API核心層作了不一樣的業務應用，以下圖所示。

再進一步詳細各個模塊的分層，咱們能夠細化爲下面的架構設計圖，全部模塊均圍繞着Web API 接口層進行擴展，底層的數據存儲對上層的應用是徹底透明，咱們能夠根據須要拆分各類業務數據庫，以及使用咱們認爲合適的數據庫。

其中咱們在Web API接口層上還看到一個微信消息交互的模塊，這個模塊咱們爲了方便域名端口的處理，和Web API 是統一放在一塊兒的，它負責和騰訊微信服務器進行消息的交互處理，從而實現各類消息推送處理。

微信的服務器架起了客戶手機和開發者服務器的一個橋樑，經過消息的傳遞和響應，實現了與用戶的交互操做，下面是它的消息流程圖。

經過對這幾類業務應用的模塊分析，咱們就能夠創建相關的項目了，來分別對這些數據和API進行管理，如咱們根據這些分類，在Visual Studio的項目管理中看到的項目以下所示。

 

其中因爲咱們這裏的Web API 是一個統一的出口，所以會整合不少Web API控制器，以提供全部業務的接口，所以對Web API 控制器的管理就顯得很重要，這裏建議引入Area區域進行管理控制器類，這種各個模塊就可以很好分門別類的進行管理了。

以下圖所示是咱們的Web API項目的控制器Area區域分類，把微信公衆號、企業號、小程序、基礎框架、第三方接口、CRM等內容進行不一樣的劃分。