整合微信小程序的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等内容进行不一样的划分。