构建插件式的应用程序框架(四)----服务容器 - 纶巾客 - 博客园

baacloud免费翻墙vpn注册使用

来源: 构建插件式的应用程序框架(四)----服务容器 – 纶巾客 – 博客园

      在构建插件式的应用程序框架(二)----订立契约一文中,可以看到我们的IApplication接口是派生于IServiceContainer接口的。为什么要派生于IServiceContainer呢?我们来看看IServiceContainer的定义,它有几个AddService方法和RemoveService方法以及从IserviceProvider继承过来的GetService方法。Service本身是.NET设计时架构的基础,Service提供设计时对象访问某项功能的方法实现,说起来还真拗口。就我看来,ServiceContainer机 制的本质就是解耦合,就是将类型的设计时功能从类型本身剥离出来。如果你把类型的设计时功能也封装到类型里,这样的类型包含了很多只有开发人员才会用到而 最终用户根本不需要的功能,使得类型既臃肿有不便于扩展。而将设计时功能剥离出来,这样类型就可以不依赖于特定的设计环境,之所以现在有这么多非官方的.NET设计环境可能就是这个原因吧。
我们的插件式的应用程序框架正好也需要这样一个松散的架构,我就移花接木把它应用到我们的框架中。
ServiceContainer是.NET提供的IserviceContainer的实现,如果没有特殊的需要我们不必扩展它,而是直接的利用它。在上一篇文章中我们在实现IApplication接口的时候就直接使用的ServiceContainer。我们在使用Service架构的时候,总是倾向于有一个根容器,各个Service容器构成了一个Service容器树,每一个节点的服务都可以一直向上传递,直到根部,而每一个节点请求Service的时候,我们总是可以从根节点获得。我把这个根节点比喻成一个服务中心,它汇总了所有可提供的服务,当某个对象要请求服务(GetService)只需要向根结点发送要获得的服务,根结点就可以把服务的对象传递给它。
从另外一个角度看,ServiceContainer为我们的插件是应用程序提供了有力的支持,利用ServiceContainer,你不但可以获得应用程序所提供的所有的功能,而且你还可以通过插件向应用程序添加Service,而你添加的Service又可以服务另外的Service,这样我们的应用程序框架就更加的灵活了。但是任何东西都是有两面性的,带来灵活的同时也为开发人员的工作增加了复杂度,所以使用ServcieContianer开发的应用程序必须提供足够详细的文档,否则开发人员可能根本不知道你到底有多少Service可以用,因为很多的Service是通过插件提供的,可能应用程序的作者都不会知道程序发布以后会出现多少Service。
写了这么多,可能接触过ServiceContainer的朋友已经觉得罗唆了,没接触过的还是觉得说得莫明其妙。有空接着写,我会创建几个简单的服务演练演练,增强一下感性认识,呵呵。

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏