前言：OSS.Social是個開源的社交網站接口集成項目，當前也有很多其他不錯的項目，不過始終沒有我想要的那種簡單清晰，只能擼起袖子，從頭打造一個。當前正在進行的是對微信項目的開發，這裏把對接口的整理，設計的思路，和項目的代碼實現方式做一個概要分享。
一. 模塊劃分
微信對外開放的接口已經非常的多，再加上時間演進的原因，可以說甚至有點雜亂。不過在大模塊上基本上還是很清晰的。
這裏針對已有的微信接口（排除支付，會在OSS.PayCenter中開源），根據接口的功能範圍，我把當前接口主要分爲以下：授權接口，功能接口，實時消息接口 三個主要模塊，每個模塊下又有子項，如下圖（在線查看，可以看到各個子項）：
1. 實時消息模塊（Msg文件夾）
主要處理實時消息的交互，在消息中又分爲普通消息和事件消息。事件消息是非常重要的一個模塊，在後續的諸多功能中起到了一個消息中樞的作用，很多重要通知都是通過這個功能推送過來的。如果接觸過消息隊列的同學，可能會發現這個事件消息就像是我們業務系統中的消息中心模塊。
2. 公衆號功能模塊（Offcial文件夾）
這個模塊主要是公衆號的一些功能接口，主要針對的對象是公衆號賬戶，這類接口都有一個共同的地方，調用時需要全局AccessToken。在這個模塊中，我又根據接口的功能對象，將功能進行相應的拆分，有了如上圖的劃分。
3. 社交接口模塊
這個模塊是最常見的模塊，主要針對的對象都是單一用戶，在像微博，豆瓣，以及所有稍微有一定規模用戶羣體的社交網站都會有這些功能，各家性質不同，接口也不一，但都會有如 Oauth 授權接口，像新浪會有發送微博等功能，微信當前主要是授權和獲取用戶基本信息。
二. 消息模塊的設計實現方式
消息模塊是微信接口中最重要的一塊功能，除了普通的消息之外，它的事件消息可以說完全是一個我們消息隊列中心，及時將各種事件push到業務方服務器上，方便我們快速處理。簡單介紹下消息模塊的實現方式。
a. 調用展示：
下圖是消息模塊的調用展示，兩種模式，一種是最基本的模式，實體和執行事件委託（event delegate）都是已經封裝好的，處理邏輯就好。 另外一種是高級模式，實體和處理方法調用註冊方法
b. 設計思路（見下方流程圖）
消息模塊中主要處理的是實時的消息接收和回覆。發起方是由微信調用，接收方處理消息執行並響應。在整個處理過程中，不管是普通消息還是事件消息，都會經歷一個完整的生命週期，在這個週期裏包含了：接收=》解析=》業務邏輯執行=》封裝消息 =》回覆
針對當前生命週期，接收和回覆都是通用的，主要是業務邏輯的不同， 在這個模塊中我們採用Handler的處理方式，由主入口進入，針對不同的消息類型採用對應的解析，執行和封裝。
也就是說開發者需要關心的只是 接收實體，執行邏輯方法和返回實體。對於微信提供的基礎消息類型來說，這裏就非常清晰了，預先定義好對應的接收實體，和相應的處理方法委託，調用時給對應的委託添加具體執行方法即可。在OSS.Social的項目中，我的實現方式是，通過泛型獲取接收實體，通過定義事件類型的委託，作爲業務邏輯方法，開發者只需要在業務方法中返回需要的消息類型即可。（爲何使用事件類型委託 ，在代碼講解章節將會講解），具體方式見上圖的基礎調用方式。
同時，除了微信自身提供的基礎消息類型之外，我們還需要考慮到後續的事件消息擴展，這裏強調一下擴展的必要性，微信的事件消息會有很多 ，同時可能隨時會有新的字段調整等，像卡券中渠道等字段。也就是說我們需要一個高級的消息處理模式，開發者能夠自己定義接收實體，以及相應的自定義事件類型。
消息生命週期執行時，我們需要知道的是： 對應的消息類型名稱，對應的實體類型，和事件方法。三個元素齊全才能完成整個生命週期，也就是說我們需要開發者在開發時傳入以上信息，底層框架能提供保存的功能，事件執行時根據對應消息類型，實例化對應的消息實體，傳入執行事件。在OSS.Social 項目中，我採用的方式是提供Register方法，底層使用ConcurrentDictionary字典保存對應的類型和方法，在解析過程中通過CreateInstance反射獲取對應的消息實體，傳入委託方法。
這裏沒有把所有的事件消息全部封裝，而是提供了一個高級消息處理模式。其一：我們要的是簡單，清晰，擴展強，全部封裝起來不僅代碼臃腫，給調用者也造成一定的限制。其次：主要是一個個全寫完，估計這雙手要擼禿皮了。
這個模塊的主要思路就是把過程流程化，明確需要哪幾個步驟，然後每個步驟可能的情況進行細化。這裏只是提供了一個簡單的概要思路，後續會有針對當前章節的詳細講解。
c. 流程圖
感興趣的同學可以去下載源碼查看，歡迎貢獻。後邊其他部分，以及相關的代碼講解都會慢慢放出來，希望大家一塊學習進步！
微信公衆號：
