我們在開發微信相關的應用的時候，一般需要完善的基礎模塊支持，包括微信公眾號，微信企業號，以及一些業務模塊的支持，一般隨著功能的增多，我們需要非常清晰的界定他們的關系。模塊的分拆以及合並往往需要考慮的代碼的重用，而且盡量做到簡單而不重復。本篇隨筆基於我的微信框架的各個模塊的功能介紹以及他們關系的描述。
微信開發，我們首先需要利用我們的語言（這裡是利用C#語言），為所有用到的API接口實現進一步的封裝，方便使用，微信API模塊包含的內容很多，大概可以分為下面的項目。
有了這些接口功能的封裝類，只是萬裡長征的第一步，我們還需要圍繞這些接口，以及我們的業務模塊實現更多交互功能的。
我們在WHC.Weixin.Data模塊裡面，定義了包含公眾號的消息分派處理接口，這個分派接口是對接收來自微信服務器的各種消息事件進行響應；另外該模塊還包含一些常規的數據存儲，如關注用戶、菜單、文章內容等方面數據的存儲，如下所示。
當然，這個WHC.Weixin.Data是集大成者，它需要使用WHC.Weixin.API的項目內容來做數據提交，同時也是需要使用內部的數據存儲處理模塊。
企業號的做法和公眾號類似，也是需要對微信提供的各種API進行封裝，方便我們後面的接口調用，不過企業號目前支持的功能相對公眾號少一些，大概包括有基礎接口、企業號應用接口、菜單管理、通訊錄管理、消息管理、搖一搖周邊等模塊。隨著企業號功能的逐步完善和加入，可能騰訊會加入更多的一些功能模塊。
同樣我們參考微信公眾號的做法，也是建立一個數據存儲管理的項目，作為微信消息事件的處理入口，同時也管理存儲一些必須的數據，包括需要同步的用戶、標簽、部門等數據。
隨著微信公眾號和企業號的功能逐漸統一，很多接口的交互數據幾乎是一樣的，因此我們可以把公用的實體類部分作為一個獨立的項目，方便公眾號和企業號兩個項目的共同使用，這個項目命名為WHC.Common.Entity。
它們幾個項目關系如下所示。
項目目錄如下所示，包括了基礎模塊、搖一搖紅包、菜單及多媒體管理模塊、消息請求模塊、消息應答模塊、搖一搖周邊、微信支付等。
由於微信支付的接口實現，是在企業號和公眾號相對比較獨立的一個API接口群，因此我們可以微信支付部分獨立作為一個接口實現來處理，公眾號或者企業號需要的時候，包含進去使用即可。
我們把它命名為WHC.Common.API項目。
還有我在前面隨筆《C#開發微信門戶及應用(42)--使用Autofac實現微信接口處理的控制反轉處理》裡面介紹過的基於對外部接口和二維碼掃碼處理接口的封裝項目，命名為WHC.Common.Handler。
整個插件業務接口包括：百度的地理位置解析接口、電影院信息查詢、天氣信息查詢、交通信息查詢、旅游信息查詢等，還有短信、郵件發送等常規接口，都可以使用這種方式進行處理。接口的效果展示如下所示。
因此上面這些以WHC.Common命名的項目，基本上就是可以通用在公眾號和企業號兩邊的項目模塊了，它們包含前面介紹過的幾個模塊，如下所示。
當然，除了這些之外，我們做項目，一般還涉及到一些基礎功能模塊，如公用類庫，以及附件管理、通訊錄管理、權限管理模塊等內容，我們可以把後者幾個模塊放在一起，組成基礎模塊。
微信界面部分是前面模塊組件的綜合使用，在微信應用裡面，一般需要使用80端口和微信服務器做交互，而這個同時往往也是我們項目的端口地址。
如果考慮的更好一些，我們可以采用以Web API優先的理念來設計整個企業應用體系的。Web API作為整個紐帶的核心，在整個核心層需要考慮到統一性、穩定性、以及安全性等方面因素。
這樣我們不管是Web項目、Winform項目，還是移動項目，都可以通過共同的接口Web API進行接入，實現更多元化的後台管理或者是前端界面呈現了。
Web API層作為一個公共的接口層，我們就很好保證了各個界面應用層的數據一致性，如果考慮到響應式的集成處理，我們甚至可以把微信應用、APP應用、Web應用做層一套Web程序，即使為了利用各自應用的特殊性，也可以把這些應用做的很相似，這樣就給用戶提供了一個統一的界面表示方式，極大提高客戶使用的界面體驗效果，用戶幾乎不需要額外的界面學習，就可以熟悉整個應用體系的各個模塊使用。
這樣最終就回到了我前面隨筆介紹過的《Web API應用架構設計分析（1）》、《Web API應用架構設計分析（2）》大平台方案了，目前我正在努力整合所有微信的接口和相關的應用在一個大的Web API平台上，逐漸整合我目前應用較為廣泛的混合式開發框架的相關技術和理念。
這樣全面構建的Web API作為核心層，可以在上面開發我們各種企業業務應用，實現我們一個大平台的整合和多元化的應用，甚至我們可以把部分模塊外包給更加擅長的團隊，我們只需要確保我們核心的Web API層安全、健壯且具有良好的擴展性即可。
