前言：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. 流程图
感兴趣的同学可以去下载源码查看，欢迎贡献。后边其他部分，以及相关的代码讲解都会慢慢放出来，希望大家一块学习进步！
微信公众号：
