WebApi 插件式构建方案
2014-11-28 17:46
155 查看
WebApi 插件式构建方案
公司要推行服务化,不可能都整合在一个解决方案内,因而想到了插件式的构建方案。最终定型选择基于 WebApi 构建服务化,之所以不使用 WCF 是因为不符合 RESTful 风格,并且对 OData 开源查询协议支持不是太好。
插件化构建的两种思路
不进行二次开发,直接把编译完成的程序集放到bin目录即可。
针对程序集寻址做扩展,把插件程序集放到
bin的二级目录。
在这里,我对两者的优缺点进行一下分析:
第一种方案:如果是临时方案我没有意见,毕竟是过渡用的,业务为重嘛。但是,作为万人敬仰的程序员,你他娘的也太懒了吧!那么多程序集放在一起,万一堆太多堆太久生蛆了肿么办?万一哪家小朋友不听话,把自己埋了肿么办?
第二种方案:嗯,还得开发,而且弄不好还会把项目搞砸!后果很严重,领导很生气!肿么办?无奈 + 无解。。。
其实不用那么麻烦,用别人开发的一套成熟的东西就好办了。没有?好,坐下来,听我慢慢说。
WebApi 启动流程简介
任何基于 Http 的服务端程序,启动管道和请求响应管道指定是跑不了的。启动管道是服务自我配置的过程:这个时候 XML 配置和一些默认的约定就起作用了,比如 IOC 容器 Unity 启动时会从
unity.config文件中读取映射配置,WebApi 框架缺省情况下会寻找从
ApiController继承并且类名称结尾是
Controller的类作为控制器。
请求响应管道是服务器接到客户端请求后的处理流程:可以想象一下我们公司里的审批流,你要请假了,必须得小组长先批准,然后总监批准,接着人力审核,财务扣钱等等。在这里,一般会首先进行认证,授权和附加信息获取等流程,最后才会交给咱程序员写的逻辑去处理。
注:对于自承载的服务,也会有一个类似的流程。
流程一:获取程序集列表
挂载在 IIS 上时,会从BuildManager中获取程序集列表:这个列表是经过 ASP.NET 程序底层优化过的,能够获取所有的程序集信息。自承载时,只是简单粗暴地调用
Assembly类的静态方法,估计会有一些问题,我没试过,这里不做讨论。考虑到绝大多数人还是使用 IIS 挂载的,说太详细没什么意义,我也没那个精力。
.Net 4.0 时代,ASP.NET 程序启动时,可以给程序集加上一个 Attribute(PreApplicationStartMethod),可以添加一些启动后不能变更的工作。这里我们要做的工作,就是把那些不在
bin根目录的程序集加载进去,通过
AddReferencedAssembly静态方法添加即可。
注意:
不要加载一个程序集的不同版本,这会对程序的运行产生不可预知的影响。
ASP.NET 的某些变量还没初始化,你的某些想法不会成立。
这里,我在加载了程序集的基础上,又公开了一些模块的元数据信息:
插件的初始配置:插件名称、路径、启动顺序、可用性、插件可见性、数据库连接字符串。
插件运行需要加载的程序集列表。
这些信息使得我在服务运行后,有了较大的定制空间。比如后面根据模块名称产生模块前缀 RESTful 服务;还有在另外的管理网站,统一管理服务的帮助系统等,源数据都是以其为依据的。
注:插件初始配置中,可用性决定了这个插件是否加载,这是总开关。
流程二:IOC 容器初始化
现代的网站,很难想象如果没有 IOC ,程序的复杂性会提升多少。所以我把 IOC 的初始化提升到最重要的位置。但是考虑到 IOC 容器不同人会有不同的选择,我这里只依照微软Unity为蓝本做讲解。至于各个插件的使用上,统一采用
CommonServiceLocator做 IOC 容器接口。
这里我解释下为什么使用
CommonServiceLocator做使用的接口方案:
接口稳定:君不见微软这么多年来,从来没更新过这货吗?
适配器丰富:可以这么说,.Net 世界的 IOC 容器,几乎都有针对的适配器。所以说,不用考虑将来更换 IOC 容器实现时,各个插件的更新问题。这根本就不是事!
公司一直在在用
Unity,而且还专门做了接口实现,没得选没的说,不解释。
根据流程一提供的插件路径,约定
Configuration\unity.config为存储接口映射的地方,在程序启动时依据插件启动顺序,逐个加载映射信息。
这一步完成后,就可以直接通过容器获取接口的实例了,很好的隔离了契约和实现,同时也让我们的程序趋于简单化,不用再用复杂的抽象工厂了。话说使用抽象工厂的配置也不比配置 IOC 容易,还都是私有的配置,一个个实现都不同,新人刚进入环境就是一头雾水。
流程三:集成加载数据库连接字符串
每个插件一般都会有自己的数据库访问功能,因为是插件化的方案,所以此时数据库连接字符串就很不好处理:生成后就不用再考虑连接字符串;插件自己放着就好,不用拷贝到指定的地方去。很幸运,.Net 提供了一个叫做反射的东西,允许做一些工作后更新到 .Net 框架自带的连接字符串容器中,这样我们就可以在运行时不用管这个叫数据库连接字符串的东东了。唯一注意的一点就是:各个插件提供的数据库连接字符串名称不能有相同的。我相信这不是什么问题!
注:这个功能的实现依赖于流程一的插件初始配置,需要添加一个连接字符串所在文件的绝对路径的东东,以便于让系统指导从哪里获取这些连接字符串。每个模块都要配置一个,当然不用数据库操作的模块可以忽略。
流程四:重写的控制器获取工厂
缺省的控制器获取工厂,只会根据约定产生诸如{controller}/{action}/{id}这类的地址,那要我们插件如何是好?万一两家写的地址一样呢?小朋友会不会找不到家了呢?在前面加上
{module}可好?
好吧,我们假设方案是可行的,我们注册
{module}/{controller}/{action}/{id}这样的路由,那就需要能解析这个路由的工厂才行啊,不然我们得不到控制器,谈何执行?
没什么可说的了,实现接口就好了,参考缺省实现,我们只需要把查找的 Key 加上模块名字就好了。
流程五:没什么可说的了
运行你的 WebApi 服务吧,网站不用引用你控制器项目,需要的时候把生成好的程序集放到 IIS 网站下你的目录就好了。这里推荐放在bin目录下面,好处是在你更新
bin下面的文件时,IIS 会重新启动这个网站。
相关文章推荐
- WebApi 插件式构建方案:集成加载数据库连接字符串
- WebApi 插件式构建方案
- WebApi 插件式构建方案:IOC 容器初始化
- WebApi 插件式构建方案:发现并加载程序集
- WebApi 插件式构建方案:重写的控制器获取工厂
- EasyNVR H5无插件直播方案前端构建之:如何播放HLS
- 使用ASP.Net WebAPI构建REST服务(一)——简单的示例
- 使用Silverlight构建插件式应用程序(附一)
- [转]构建插件式的应用程序框架(四)----服务容器
- .net构建插件式的应用程序框架1
- js构建ui的统一异常处理方案(三)
- 构建插件式的应用程序框架(二)----订立契约
- 构建插件式的应用程序框架(五)----管理插件
- 构建插件式的应用程序框架(五)----管理插件(ZT)
- 手把手教你构建 Android WebView 的缓存机制 & 资源预加载方案
- 如何快速、低成本构建一套稳定、高效、可靠的互联网主播直播/商业直播(推流/分发/播放)方案
- WebAPI的一种单元测试方案
- WebApi参数问题方案
- 【好文收藏】基于OpenStack和Kubernetes构建组合云平台——网络集成方案综述