?前言：OSS.Social是個開源的社交網(wǎng)站接口集成項目枷畏，當(dāng)前也有很多其他不錯的項目忽匈，不過始終沒有我想要的那種簡單清晰，只能擼起袖子矿辽，從頭打造一個丹允。當(dāng)前正在進(jìn)行的是對微信項目的開發(fā)郭厌，這里把對接口的整理，設(shè)計的思路雕蔽，和項目的代碼實現(xiàn)方式做一個概要分享折柠。
一. 模塊劃分
?微信對外開放的接口已經(jīng)非常的多，再加上時間演進(jìn)的原因批狐，可以說甚至有點雜亂扇售。不過在大模塊上基本上還是很清晰的。
?這里針對已有的微信接口（排除支付嚣艇，會在OSS.PayCenter中開源）承冰，根據(jù)接口的功能范圍，我把當(dāng)前接口主要分為以下：授權(quán)接口食零，功能接口困乒，實時消息接口 三個主要模塊，每個模塊下又有子項贰谣，如下圖（在線查看娜搂，可以看到各個子項）：
1. 實時消息模塊（Msg文件夾）
?主要處理實時消息的交互，在消息中又分為普通消息和事件消息吱抚。事件消息是非常重要的一個模塊百宇，在后續(xù)的諸多功能中起到了一個消息中樞的作用，很多重要通知都是通過這個功能推送過來的秘豹。如果接觸過消息隊列的同學(xué)携御，可能會發(fā)現(xiàn)這個事件消息就像是我們業(yè)務(wù)系統(tǒng)中的消息中心模塊。
2. 公眾號功能模塊（Offcial文件夾）
?這個模塊主要是公眾號的一些功能接口既绕，主要針對的對象是公眾號賬戶啄刹，這類接口都有一個共同的地方，調(diào)用時需要全局AccessToken岸更。在這個模塊中，我又根據(jù)接口的功能對象膊升，將功能進(jìn)行相應(yīng)的拆分怎炊，有了如上圖的劃分。
3. 社交接口模塊
?這個模塊是最常見的模塊廓译，主要針對的對象都是單一用戶评肆，在像微博，豆瓣非区，以及所有稍微有一定規(guī)模用戶群體的社交網(wǎng)站都會有這些功能瓜挽，各家性質(zhì)不同，接口也不一征绸，但都會有如 Oauth 授權(quán)接口久橙，像新浪會有發(fā)送微博等功能俄占，微信當(dāng)前主要是授權(quán)和獲取用戶基本信息。
二. 消息模塊的設(shè)計實現(xiàn)方式
消息模塊是微信接口中最重要的一塊功能淆衷，除了普通的消息之外缸榄，它的事件消息可以說完全是一個我們消息隊列中心，及時將各種事件push到業(yè)務(wù)方服務(wù)器上祝拯，方便我們快速處理甚带。簡單介紹下消息模塊的實現(xiàn)方式。
a. ?調(diào)用展示：
?下圖是消息模塊的調(diào)用展示佳头，兩種模式鹰贵，一種是最基本的模式，實體和執(zhí)行事件委托（event delegate）都是已經(jīng)封裝好的康嘉，處理邏輯就好碉输。 另外一種是高級模式，實體和處理方法調(diào)用注冊方法
b. ?設(shè)計思路（見下方流程圖）
??消息模塊中主要處理的是實時的消息接收和回復(fù)凄鼻。發(fā)起方是由微信調(diào)用腊瑟，接收方處理消息執(zhí)行并響應(yīng)。在整個處理過程中块蚌，不管是普通消息還是事件消息闰非，都會經(jīng)歷一個完整的生命周期，在這個周期里包含了：接收=》解析=》業(yè)務(wù)邏輯執(zhí)行=》封裝消息 =》回復(fù)
?針對當(dāng)前生命周期峭范，接收和回復(fù)都是通用的财松，主要是業(yè)務(wù)邏輯的不同， 在這個模塊中我們采用Handler的處理方式纱控，由主入口進(jìn)入辆毡，針對不同的消息類型采用對應(yīng)的解析，執(zhí)行和封裝甜害。
?也就是說開發(fā)者需要關(guān)心的只是 接收實體舶掖，執(zhí)行邏輯方法和返回實體。對于微信提供的基礎(chǔ)消息類型來說尔店，這里就非常清晰了眨攘，預(yù)先定義好對應(yīng)的接收實體，和相應(yīng)的處理方法委托嚣州，調(diào)用時給對應(yīng)的委托添加具體執(zhí)行方法即可鲫售。在OSS.Social的項目中，我的實現(xiàn)方式是该肴，通過泛型獲取接收實體情竹，通過定義事件類型的委托，作為業(yè)務(wù)邏輯方法匀哄，開發(fā)者只需要在業(yè)務(wù)方法中返回想要需要的消息類型即可秦效。（為何使用事件類型委托 雏蛮，在代碼講解章節(jié)將會講解），具體方式見上圖的基礎(chǔ)調(diào)用方式棉安。
?同時底扳，除了微信自身提供的基本的消息類型之外，我們還需要考慮到后續(xù)的事件消息擴(kuò)展贡耽，這里強(qiáng)調(diào)一下擴(kuò)展的必要性衷模，微信的事件消息會有很多 ，同時可能隨時會有新的字段調(diào)整等蒲赂，像卡券中渠道等字段阱冶。也就是說我們需要一個高級的消息處理模式，開發(fā)者能夠自己定義接收實體滥嘴，以及相應(yīng)的自定義事件類型木蹬。
?消息生命周期執(zhí)行時，我們需要知道的是： 對應(yīng)的消息類型名稱若皱，對應(yīng)的實體類型镊叁，和事件方法，才能完成整個生命周期走触，也就是說我們需要開發(fā)者在開發(fā)時傳入以上信息晦譬，底層框架能提供保存的功能，事件執(zhí)行時根據(jù)對應(yīng)消息類型互广，實例化對應(yīng)的消息實體敛腌，傳入執(zhí)行事件。在OSS.Social 項目中惫皱，我采用的方式是提供Register方法像樊，底層使用ConcurrentDictionary字典保存對應(yīng)的類型和方法，在解析過程中通過CreateInstance反射獲取對應(yīng)的消息實體旅敷，傳入委托方法生棍。
?這里沒有把所有的事件消息全部封裝，而是提供了一個高級消息處理模式媳谁。其一：我們要的是簡單涂滴，清晰，擴(kuò)展強(qiáng)韩脑，全部封裝起來不僅代碼臃腫氢妈，給調(diào)用者也造成一定的限制粹污。其次：主要是一個個全寫完段多，估計這雙手要擼禿皮了。
?
?這個模塊的主要思路就是把過程流程化壮吩，明確需要哪幾個步驟进苍，然后每個步驟可能的情況進(jìn)行細(xì)化加缘。這里只是提供了一個簡單的概要思路，后續(xù)會有針對當(dāng)前章節(jié)的詳細(xì)講解觉啊。
c. 流程圖
感興趣的同學(xué)可以去下載源碼查看拣宏，歡迎貢獻(xiàn)。后邊其他部分杠人，以及相關(guān)的代碼講解都會慢慢放出來勋乾，希望大家一塊學(xué)習(xí)進(jìn)步！
微信公眾號：
