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

      在构建插件式的应用程序框架(二)－－－－订立契约一文中，可以看到我们的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的朋友已经觉得罗唆了，没接触过的还是觉得说得莫明其妙。有空接着写，我会创建几个简单的服务演练演练，增强一下感性认识，呵呵。